ES 内存使用和GC指标——主节点每30秒会去检查其他节点的状态,如果任何节点的垃圾回收时间超过30秒(Garbage collection duration),则会导致主节点任务该节点脱离集群。

  1. 云栖社区>
  2. 博客>
  3. 正文

ES 内存使用和GC指标——主节点每30秒会去检查其他节点的状态,如果任何节点的垃圾回收时间超过30秒(Garbage collection duration),则会导致主节点任务该节点脱离集群。

桃子红了呐 2017-11-16 17:07:00 浏览1150
展开阅读全文

摘录自: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。
















本文转自张昺华-sky博客园博客,原文链接:http://www.cnblogs.com/bonelee/p/8063915.html,如需转载请自行联系原作者


网友评论

登录后评论
0/500
评论
桃子红了呐
+ 关注