JVM对ElasticSearch集群的稳定性有很大的影响。
Java是一个垃圾收集语言，意思是这个程序不会手动管理分配和释放内存。程序员只需要编写代码，jvm管理根据需要管理分配内存的处理，然后在不需要的时候清理。
------------
Young (or Eden)
当新实例一个对象的时候分配的空间，新生代的空间一般比较小，通常是100MB-500MB，新生代也包含了2个幸存(survivor)空间。
Old
存储较老的对象空间。这些对象预期是长久的并且持续了很长时间。老年代一般比新生代空间大得多，在ElasticSearch节点中最大可以设置为30GB。
当一个对象被实例化，它将被放到新生代。当新生代空间快满的时候，开始新生代垃圾收集(GC)，仍然”活着“的对象移到survivor空间，不再用的对象被移除，如果一个对象在几次新生代GC中survived下来，它将被永远被放在老年代。
类似的情况发生在老年代，当空间快满时，开始GC移除不再用的对象。
对于空间比较小的新生代GC执行很快，但对于老年代来说就比较慢了，一个缓慢的GC可能有1s甚至15s以上，这对于服务是不可接受的。
JVM中的GC是非常复杂的算法，可以最小化停顿。ElasticSearch非常努力的试图使GC变得友好，通过智能重用内部对象、网络缓存区并默认启用文档值，但最终，GC 的次数和持续的时间是需要观察的指标，因为它是集群不稳定性的第一个罪归祸首。
一个频繁长时间GC的集群是重负载并且没有足够的内存的。这些长时间GC将使节点短暂的离开集群。在elasticsearch中为了保持集群的稳定和可用的副本，这种不稳定因素经常导致重新迁移分片。当你的集群尝试服务正常的索引和查询时，这反过来增加了网络流量和磁盘I/O负载。
简而言之，长时间GC是危险的，需要尽可能的减少它的时间。
-----------
elasticsearch进行节点的jvm的查询 GET /_nodes/stats
"jvm": { "timestamp": 1548299273773, "uptime_in_millis": 14520625479, "mem": { "heap_used_in_bytes": 3969664840, "heap_used_percent": 74, "heap_committed_in_bytes": 5333843968, "heap_max_in_bytes": 5333843968, "non_heap_used_in_bytes": 201659512, "non_heap_committed_in_bytes": 222814208, "pools": { "young": { "used_in_bytes": 206922552, "max_in_bytes": 279183360, "peak_used_in_bytes": 279183360, "peak_max_in_bytes": 279183360 }, "survivor": { "used_in_bytes": 9508904, "max_in_bytes": 34865152, "peak_used_in_bytes": 34865152, "peak_max_in_bytes": 34865152 }, "old": { "used_in_bytes": 3753233384, "max_in_bytes": 5019795456, "peak_used_in_bytes": 3802246240, "peak_max_in_bytes": 5019795456 } } } }
注意：
1. heap_committed_in_bytes应该和heap_max_in_bytes相同，如果这个committed大小更小，JVM将会重新调整堆栈，这是个非常耗费资源的过程。
2. heap_used_percent这个指标是非常有用的，当heap达到75%时启动GC。如果节点一直大于75%，节点内存将有压力，这是一个警告信号，表示缓慢的GC将会在不久发生。 如果heap使用一直大于85%，elasticsearch可能会出现异常，超过90-95%伴随着GC时间达到10-30s将面临性能风险，并有可能引发一个内存溢出异常(OOM)。