[翻译]Elasticsearch重要文章之四:监控每个节点(jvm部分)

操作系统和进程部分

操作系统和进程部分的含义是很清楚的,这里不会描述的很详细。他们列出了基本的资源统计,例如CPU和负载。操作系统部分描述了整个操作系统的情况,进程部分只是描述了Elasticsearch的JVM进程的使用情况。

这显然是很有用的统计, 但是往往会被忽视,一些统计包括如下部分:

>CPU
>负载
>内存使用情况
>swap使用情况
>打开文件句柄数

JVM部分
jvm部分包含一些有关于运行elasticsearch的jvm进程的关键信息。最重要的是,它包含了垃圾回收方面的细节,这对你的elasticsearch的集群的稳定性有很大影响。

>垃圾收集(GC)入门

在我们描述这个之前,很有必要先介绍下GC以及它对elasticsearch的影响。如果你对jvm中的GC很熟悉,可以跳过这一章。

java是一个自己进行垃圾回收的语言,也就是说程序员不需要主动管理内存的分配和释放。程序员只要专心写自己的代码,java虚拟机会管理根据需要分配内存的过程,然后当内存不再使用的时候,它自己会去释放。

当内存被分配给JVM进程,它会被分配成一个叫堆的大块区域。JVM会把这个堆分成两组,叫做“代”:

年轻代(或者伊甸园)

新实例化的对象就在这里分配空间,年轻代的空间通常很小,大约100MB-500MB。年轻代包含两个幸存者区域

老年代

存储那些老的对象的区域。这些对象是长期存在,并且持续很长时间。老年代通常比年轻代大很多。你可以看到elasticsearch节点的老年代可能大到30GB

当一个对象被实例化后,它会被放置到年轻代,当年轻代的空间满了,一个年轻代的垃圾回收就启动了。那些仍然存活的对象就会被移动到其中一个幸存者区域。而死了的对象就会被清除了。如果一个对象在年轻代中经历了多次GC仍然幸存,那它将被晋升到老年代。

类似的过程也发生在老年代,当老年代的空间越来越满了,一个垃圾回收就启动了,同时死了对象会被清除。

天下没有免费的午餐,年轻代和老年代的垃圾回收都包含一个“stop-the-world”的阶段。在这个时间内,JVM会停止程序的执行,进行对象的标记和收集,在这个stop-the-world的阶段,没有任何事情发生,请求不会被处理,ping不会被会回应。shards不会再进行迁移。整个世界真的停止了。

对于年轻代这不是一个问题,因为它很小,GC执行的很快。但是对于大一点的老年代,缓慢的GC意味着1s甚至15s的停顿,这对于一个服务器软件来说是不可接受的。

垃圾回收在JVM是很复杂的算法,为了减少停顿做了很多的工作。同时Elasticsearch很努力适应GC,比如通过内部对象的重用,利用网络缓冲区,并挺贵一些特征值例如文档的数量。但是GC的频率和长短是需要你特别留意的信息,因为它是集群不稳定的头号元凶。

如果一个集群经常性的发生长时间GC,那么你的集群一定内存不足并且负载特别高。这些长时间GC会导致节点周期性的脱离集群。这种不稳定会导致分片数据不断的重新生成,以保证集群内的平衡以及足够的分片数量。这会增加网络贷款和磁盘IO,同时你的集群还要承担进行正常的索引数据和查询。

简而言之,长时间的GC是很糟糕的,需要尽可能的减少。

因为GC对Elasticsearch如此重要,你必须对node stats的API显示的这个部分特别熟悉才行。

"jvm": {
	"timestamp": 1408556438203,
	"uptime_in_millis": 14457,
	"mem": {
	   "heap_used_in_bytes": 457252160,
	   "heap_used_percent": 44,
	   "heap_committed_in_bytes": 1038876672,
	   "heap_max_in_bytes": 1038876672,
	   "non_heap_used_in_bytes": 38680680,
	   "non_heap_committed_in_bytes": 38993920,

jvm部分首先列出的是有关堆内存使用情况的一般情况,你可以看到多少heap被用到,有多少可以被使用(已经分配了线程),还有堆内存最大可以长到多少。理想情况下heap_committed_in_bytes应该和heap_max_in_bytes相同,如果被分配的堆较小,那JVM将会不得不调整堆的大小,这个过程代价是很高的。如果你的这两个值是不同的,请看《Heap: Sizing and Swapping》章节,确认你配置的是否正确。

heap_used_percent 是你必须盯着看的一个有用的参数。Elasticsearch配置的是当堆使用到75%的时候进行GC,如果你的节点总是大约75%,那你节点正在承受内存方面的压力,这是一个告警,预示着你不久就会出现慢GC。

如果你的heap使用率一直在85%以上,那你有麻烦了,90-95%的概率会因为10-30s的GC 发生性能问题,这还是好的,最坏的就是发生内存溢出。

"pools": {
      "young": {
         "used_in_bytes": 138467752,
         "max_in_bytes": 279183360,
         "peak_used_in_bytes": 279183360,
         "peak_max_in_bytes": 279183360
      },
      "survivor": {
         "used_in_bytes": 34865152,
         "max_in_bytes": 34865152,
         "peak_used_in_bytes": 34865152,
         "peak_max_in_bytes": 34865152
      },
      "old": {
         "used_in_bytes": 283919256,
         "max_in_bytes": 724828160,
         "peak_used_in_bytes": 283919256,
         "peak_max_in_bytes": 724828160
      }
   }
},

young, survivor, and old sections 显示了每个代在GC中的使用情况,供你分析。这些数据方便你看到他们的相对大小,但是对于你调查问题往往不是很重要。

gc": {
   "collectors": {
      "young": {
         "collection_count": 13,
         "collection_time_in_millis": 923
      },
      "old": {
         "collection_count": 0,
         "collection_time_in_millis": 0
      }
   }
}

gc区域显示的GC的次数和时间,包括年轻代和老年代。大部分时间,你可以忽略关于年轻代的手机次数,这个次数往往很大,这是很正常的。

相反,老年代的GC应该少一点,collection_time_in_millis也要小。这是个累计数字,很难给你一个你应该担心时候的数字(举个例子,一个节点运行了一年,可能有很多次GC,但是这个节点却很健康稳定)。这也是一些工具例如Maverl特别有用的原因。多长时间内的GC次数是个很重要的考虑因素。

花在GC上的时间也很重要,例如,在索引数据的时候会产生一定量的内存垃圾,这很正常,会让GC不时的发生。这些GC通常都是很快的,对节点也没有多少英雄。年轻代只需要一两毫秒。老年代可能需要几百毫秒。这和十秒级的GC是很大不同的。

我们最佳的建议是周期性的收集GC的个数和时间(或者使用Marverl) 并且留意频繁GC,你也可以打开慢GC日志,记录在日志里。

  1. 大a先生说道:

    你好,请问你上面的jvm相关的监控信息是通过什么途径获取到的呢

留言

提示:你的email不会被公布,欢迎留言^_^

*

验证码 *