Elasticsearch的[monitor.jvm]垃圾回收日志

来源：互联网发布：男生紧身裤知乎编辑：程序博客网时间：2024/04/29 03:10

Elasticsearch最近刚刚更名为Elastic，1.5.2 版本也已经出来了，只是Kibana、Sense等一大票工具不再免费了 (具体价格可以参见 - Subscriptions)，让人有点蛋蛋的桑心！呵呵，毕竟是个好项目，人家也要挣钱去养家糊口，希望之后的版本能够更稳定，特别是在系统升级的稳定性方面。最近刚将生产环境由1.2.2升级到1.4.4，相对上一次1.1.1到1.2.2，这次总体还是平稳的，但还是有些意料之外的问题 -checksum check。

Elasticsearch是构建在Java之上的、开源的、分布式搜索和分析引擎，因此JVM的性能对Elasticsearch性能至关重要。在负载超出节点所能承受的情况下，JVM垃圾内存回收的“Stop-The-World”会造成节点被踢出Elasticsearch集群。如果只是偶尔发生，Elasticsearch的冗余设计可以克服（如: Replica # = 1）。但如果是经常出现节点被踢出的情况，则会对整个集群的稳定造成很致命的影响，很可能会造成数据的丢失，这就需要认真排查一下节点被踢出的原因。

如果是因为JVM的“Stop-The-World”造成的，则在Elasticsearch的日志中一定可以看到[monitor.jvm ]日志。根据程度不同，它分为 INFO, WARN和DEBUG。下面是一些笔者遇到过的例子：

例-1

[2015-04-1900:09:52,783][INFO ][monitor.jvm ] [ES-DIAG2-16-data] [gc][young][3402090][244044] duration [887ms],collections [1]/[1.5s], total [887ms]/[3.3h], memory [4.5gb]->[4gb]/[6.9gb],all_pools {[young] [499.4mb]->[782.8kb]/[532.5mb]}{[survivor][32.7mb]->[30.2mb]/[66.5mb]}{[old] [3.9gb]->[3.9gb]/[6.3gb]}

上面这个例子的情况无须紧张，只是young gc，并且只用了887ms，对于Elasticsearch而言，没有啥影响。唯一需要留心的是，如果在日志中出现连续的和长时间的young gc，则需要引起警觉，可能是你的Heap内存分配不够。

例-2

[2014-05-0218:54:14,630][WARN][monitor.jvm ] [ES-DIAG-35-data] [gc][old][76581][22] duration [3.1m], collections[2]/[3.1m], total [3.1m]/[3.1m], memory [3gb]->[1.2gb]/[3.4gb], all_pools{[young] [251mb]->[74.9mb]/[266.2mb]}{[survivor][25.8mb]->[0b]/[33.2mb]}{[old] [2.8gb]->[1.1gb]/[3.1gb]}

如果这种JVM出现，则你的节点一定被踢出了集群。old gc是比较耗时，上面这个例子用了3.1分钟，一定是出了啥大事，要不是然“世界”不会停转这么久的，呵呵！

例-3

[2015-04-1815:33:33,287][WARN][monitor.jvm ] [ES-DIAG-X-master] [gc][old][160117][1326] duration [41.4s], collections [2]/[42.4s],total [41.4s]/[4.7h], memory [3.4gb]->[3.4gb]/[3.4gb], all_pools {[young][266.2mb]->[266.2mb]/[266.2mb]}{[survivor][33.2mb]->[33.2mb]/[33.2mb]}{[old] [3.1gb]->[3.1gb]/[3.1gb]}

这个例子相对于例-2而言更为严重，虽然old gc只让“世界”停了41.4秒，但gc之后，young，survivor和old都已经没有有可用的内存空间了。这种情况发生时，你会看到日志中满满的都是这样的日志，也一定会有 "java.lang.OutOfMemoryError: Java heap space"相伴。你摊上事儿了，摊上大事儿了，呵呵！

一般情况下造成JVM "Stop-The-World"的原因是由于heap内存分配不够，适当的增加内存可以解决问题。当然也不是heap内存越大越好，32GB是个极限，超过这个极限性能反而会下降，具体请参阅Limiting Memory Usage 和 Heap:Sizing and Swapping。

此外，造成JVM "Stop-The-World"的原因也是多方面的，没有包治百病的神药，需要去分析和测试实际生产环境下Elasticsearch集群的负载和配置。Elasticsearch已经提供了很多内部参数帮助我们了解系统节点的运行情况，建议大家好好阅读Monitoring Individual Nodes 这篇文档，了解这些参数的意义。Six Ways to Crash Elasticsearch 也给出一些可以让Elasticsearch崩溃的例子。

参考内容

http://jprante.github.io/2012/11/28/Elasticsearch-Java-Virtual-Machine-settings-explained.html

0 0