elasticsearch 的内存JVM和GC相关问题

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": ,
    "uptime_in_millis": ,
    "mem": {
      "heap_used_in_bytes": ,
      "heap_used_percent": ,
      "heap_committed_in_bytes": ,
      "heap_max_in_bytes": ,
      "non_heap_used_in_bytes": ,
      "non_heap_committed_in_bytes": ,
      "pools": {
        "young": {
          "used_in_bytes": ,
          "max_in_bytes": ,
          "peak_used_in_bytes": ,
          "peak_max_in_bytes":
        },
        "survivor": {
          "used_in_bytes": ,
          "max_in_bytes": ,
          "peak_used_in_bytes": ,
          "peak_max_in_bytes":
        },
        "old": {
          "used_in_bytes": ,
          "max_in_bytes": ,
          "peak_used_in_bytes": ,
          "peak_max_in_bytes":
        }
      }
    }
}

注意：
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)。