个人没有具体实践过，下面是一些想法，你可以参考一下。
 
首先应该查找出现长 GC 的原因，如果实在难以解决，想通过杀死进程等手段重启 ES 来达到目的，可以考虑下面的方法：
业务系统启动一个定时器，去请求 _cluster/health，当出现 Full GC 的时候，这个 API 就无法及时响应了，会出现请求 timeout 的情况，你可以在 timeout 时候做进一步判断，是否处于 GC，然后对进程进行重启等操作。
 
不过应该有一些其他工具可以检测，百度结果是通过下面的命令行： jstat -gc 进程号  间隔时间
通过上述的命令行可以监控某一个进程的 GC 情况，具体请参考：https://blog.csdn.net/zlzlei/a ... 71627
 
当然通过在 ES 启动命令里面添加 -XX:+PrintGCDetails 即可打印详细的 GC 日志，通过检测日志一样可以获取 GC 情况；
 
最后，可以通过集群 API 
GET _nodes/stats
获取集群内机器的概览情况，其中就包含了 jvm 的 gc 情况

"jvm": {

            "timestamp": 1408556438203,

            "uptime_in_millis": 14457,

            "mem": {

               "heap_used_in_bytes": 457252160,

               "heap_used_percent": 44,

               "heap_committed_in_bytes": 1038876672,

               "heap_max_in_bytes": 1038876672,

               "non_heap_used_in_bytes": 38680680,

               "non_heap_committed_in_bytes": 38993920,

 
具体请参考：https://www.elastic.co/guide/e ... ction

可以将堆设置小一点，可以使用g1回收器，针对回收时间有优化

貌似 ES 默认开启了 GC 日志
在 jvm.options 看到下面的配置

8:-XX:+PrintGCDetails

8:-XX:+PrintGCDateStamps

8:-XX:+PrintTenuringDistribution

8:-XX:+PrintGCApplicationStoppedTime

8:-Xloggc:logs/gc.log

8:-XX:+UseGCLogFileRotation

8:-XX:NumberOfGCLogFiles=32

8:-XX:GCLogFileSize=64m