内存使用和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 |
| Other |
Total time spent on young-generation garbage collections |
| Other |
Total count of old-generation garbage collections |
| Other |
Total time spent on old-generation garbage collections |
| Other |
Percent of JVM heap currently in use |
| Resource: Utilization |
Amount of JVM heap committed |
| 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。