摘录自：http://blog.csdn.net/yangwenbo214/article/details/74000458
内存使用和GC指标
在运行Elasticsearch时，内存是您要密切监控的关键资源之一。 Elasticsearch和Lucene以两种方式利用节点上的所有可用RAM：JVM heap和文件系统缓存。 Elasticsearch运行在Java虚拟机（JVM）中，这意味着JVM垃圾回收的持续时间和频率将成为其他重要的监控领域。
JVM heap: A Goldilocks tale
Elasticsearch强调了JVM堆大小的重要性，这是“正确的” - 不要将其设置太大或太小，原因如下所述。 一般来说，Elasticsearch的经验法则是将少于50％的可用RAM分配给JVM堆，而不会超过32 GB。
您分配给Elasticsearch的堆内存越少，Lucene就可以使用更多的RAM，这很大程度上依赖于文件系统缓存来快速提供请求。 但是，您也不想将堆大小设置得太小，因为应用程序面临来自频繁GC的不间断暂停，可能会遇到内存不足错误或吞吐量降低的问题
Elasticsearch的默认安装设置了1 GB的JVM heap大小，对于大多数用例来说，太小了。 您可以将所需的heap大小导出为环境变量并重新启动Elasticsearch:
export ES_HEAP_SIZE=10g
如上我们设置了es heap大小为10G，通过如下命令进行校验：
curl -XGET http://:9200/_cat/nodes?h=heap.max
Garbage collection
Elasticsearch依靠垃圾收集过程来释放heap memory。因为垃圾收集使用资源（为了释放资源！），您应该注意其频率和持续时间，以查看是否需要调整heap大小。设置过大的heap会导致GC时间过长，这些长时间的停顿会让集群错误的认为该节点已经脱离。
| Metric description | Name | [Metric type][monitoring-101-blog] |
|---|---|---|
| Total count of young-generation garbage collections | jvm.gc.collectors.young.collection_count(jvm.gc.collectors.ParNew.collection_count prior to vers. 0.90.10) |
Other |
| Total time spent on young-generation garbage collections | jvm.gc.collectors.young.collection_time_in_millis(jvm.gc.collectors.ParNew.collection_time_in_millis prior to vers. 0.90.10) |
Other |
| Total count of old-generation garbage collections | jvm.gc.collectors.old.collection_count(jvm.gc.collectors.ConcurrentMarkSweep.collection_count prior to vers. 0.90.10) |
Other |
| Total time spent on old-generation garbage collections | jvm.gc.collectors.old.collection_time_in_millis(jvm.gc.collectors.ConcurrentMarkSweep.collection_time_in_millis for versions prior to 0.90.10) |
Other |
| Percent of JVM heap currently in use | jvm.mem.heap_used_percent |
Resource: Utilization |
| Amount of JVM heap committed | jvm.mem.heap_committed_in_bytes |
Resource: Utilization |
JVM指标的要点：
-
-
JVM heap in use: 当JVM heap 使用率达到75％时，es启动GC。如上图所示，可以监控node的JVM heap，并且设置一个警报，确认哪个节点是否一直超过%85。如果一直超过，则表明垃圾的收集已经跟不上垃圾的产生。此时可以通过增加heap（需要满足建议法则不超过32G），或者通过增加节点来扩展集群，分散压力。
-
JVM heap used vs. JVM heap committed: 与commit的内存（保证可用的数量）相比，了解当前正在使用多少JVM heap的情况可能会有所帮助。heap memory的图一般是个锯齿图，在垃圾收集的时候heap上升，当收集完成后heap下降。如果这个锯齿图向上偏移，说明垃圾的收集速度低于rate of object creation，这可能会导致GC时间放缓，最终OutOfMemoryErrors。
-
Garbage collection duration and frequency: Both young- and old-generation garbage collectors undergo “stop the world” phases, as the JVM halts execution of the program to collect dead objects。在此期间节点cannot complete any task。主节点每30秒会去检查其他节点的状态，如果任何节点的垃圾回收时间超过30秒，则会导致主节点任务该节点脱离集群。
-
Memory usage: 如上所述，es非常会利用除了分配给JVM heap的任何RAM。像Kafka一样，es被设计为依赖操作系统的文件系统缓存来快速可靠地提供请求。
许多变量决定了Elasticsearch是否成功读取文件系统缓存，如果segment file最近由es写入到磁盘，它已经in the cache。然而如果节点被关闭并重新启动，首次查询某个segment的时候，数据很可能是必须从磁盘中读取，这是确保您的群集保持稳定并且节点不会崩溃的重要原因之一。
总的来说，监控节点上的内存使用情况非常重要，并且尽可能多给es分配RAM，so it can leverage the speed of the file system cache without running out of space。
-
