ElasticSearch的JVM浅谈（转）

JVM对ElasticSearch集群的稳定性有很大的影响。

Java是一个垃圾收集语言，意思是这个程序不会手动管理分配和释放内存。程序员只需要编写代码，jvm管理根据需要管理分配内存的处理，然后在不需要的时候清理。

Young (or Eden)
当新实例一个对象的时候分配的空间，新生代的空间一般比较小，通常是100MB-500MB，新生代也包含了2个幸存(survivor)空间。

Old
存储较老的对象空间。这些对象预期是长久的并且持续了很长时间。老年代一般比新生代空间大得多，在ElasticSearch节点中最大可以设置为30GB。

当一个对象被实例化，它将被放到新生代。当新生代空间快满的时候，开始新生代垃圾收集(GC)，仍然”活着“的对象移到survivor空间，不再用的对象被移除，如果一个对象在几次新生代GC中survived下来，它将被永远被放在老年代。

类似的情况发生在老年代，当空间快满时，开始GC移除不再用的对象。

对于空间比较小的新生代GC执行很快，但对于老年代来说就比较慢了，一个缓慢的GC可能有1s甚至15s以上，这对于服务是不可接受的。

JVM中的GC是非常复杂的算法，可以最小化停顿。ElasticSearch非常努力的试图使GC变得友好，通过智能重用内部对象、网络缓存区并默认启用文档值，但最终，GC 的次数和持续的时间是需要观察的指标，因为它是集群不稳定性的第一个罪归祸首。

一个频繁长时间GC的集群是重负载并且没有足够的内存的。这些长时间GC将使节点短暂的离开集群。在elasticsearch中为了保持集群的稳定和可用的副本，这种不稳定因素经常导致重新迁移分片。当你的集群尝试服务正常的索引和查询时，这反过来增加了网络流量和磁盘I/O负载。

简而言之，长时间GC是危险的，需要尽可能的减少它的时间。

node-stats API:

“jvm”: {
“timestamp”: 1483246917484,
“uptime_in_millis”: 679408297,
“mem”: {
“heap_used_in_bytes”: 17235461384,
“heap_used_percent”: 55,
“heap_committed_in_bytes”: 30780620800,
“heap_max_in_bytes”: 30780620800,
“non_heap_used_in_bytes”: 137928872,
“non_heap_committed_in_bytes”: 141455360,

}
}
heap_committed_in_bytes应该和heap_max_in_bytes相同，如果这个committed大小更小，JVM将会重新调整堆栈，这是个非常昂贵的过程。如果你的数字不一样，参考Heap: Sizing and Swapping如何正确配置。
heap_used_percent这个指标是非常有用的，当heap达到75%时启动GC。如果节点一直大于75%，节点内存将有压力，这是一个警告信号，表示缓慢的GC将会在不久发生。
如果heap使用一直大于85%，你将有麻烦来了，超过90-95%伴随着GC时间达到10-30s将面临性能风险，并有可能引发一个异常out-of-memory(OOM)
“pools”: {
“young”: {
“used_in_bytes”: 3525862600,
“max_in_bytes”: 5726666752,
“peak_used_in_bytes”: 5726666752,
“peak_max_in_bytes”: 5726666752
},
“survivor”: {
“used_in_bytes”: 77053512,
“max_in_bytes”: 1431633920,
“peak_used_in_bytes”: 618333600,
“peak_max_in_bytes”: 1431633920
},
“old”: {
“used_in_bytes”: 13631010160,
“max_in_bytes”: 23622320128,
“peak_used_in_bytes”: 17722183576,
“peak_max_in_bytes”: 23622320128
}
}
这个young、survivor和old部分提供在GC中每个代的内存使用情况。这些统计数据方便你查看相对大小，但在调试问题时通常不太重要。
“gc”: {
“collectors”: {
“young”: {
“collection_count”: 35879,
“collection_time_in_millis”: 1954077
},
“old”: {
“collection_count”: 6,
“collection_time_in_millis”: 4782
}
}
}
gc部分展示了young和old垃圾收集的数量和累积的时间。大部分可以安全的忽略young的数量。数量是非常大的，这是完全正常的。
相反，old垃圾收集数量应该是非常少的，同时collection_time_in_millis也会比较小。这是个累计数，所以很难给出一个具体的数字代表它出现了问题。（例如：一个运行了一年的节点将具有非常大的计数，即使它是正常的）。
花在GC上的时间也非常重要。（例如：在索引一个文档时将生成一些垃圾）。这些GC几乎总是快速并且对节点几乎没有影响。young需要1ms或2ms，而old需要几百毫秒，这和需要10s的GC截然不同。
启用slow-GC日志
线程池

ElasticSearch在内部管理线程池，这些线程池合作完成任务，根据需要在彼此传递工作。通常不需要配置或调整线程池，但是有时候查看这些统计信息是非常有益的，可以了解集群的状态。
有大约十二个线程池，但都是一样的格式：

“bulk”: {
“threads”: 0,
“queue”: 0,
“active”: 0,
“rejected”: 0,
“largest”: 0,
“completed”: 0
}
每个线程池列出了配置的线程数(threads)，有多少个活动的线程正在工作(active)，有多少个工作单位在一个队列(queue)。
如果一个队列被填满到限制，新的工作单位将被拒绝(rejected)，这通常是一个信号，表示集群上资源到了一定瓶颈。一旦队列满了意味着节点/集群正在以最大的速度处理但跟不上涌入的请求。
Bulk Rejections

如果遇到队列拒绝，很有可能是批量索引请求。
通常每个集群都有其跟不上涌入请求的某些限制，一旦超过阀值，这个队列将被填满，然后新的批量请求将被拒绝。
这是一件好事，对减缓压力，队列拒绝是非常有用。这能让你知道你的集群的最大容量。这比粘贴数据到内存队列好得多。更多的队列大小并不能提高性能，只是隐藏了这个问题。如果你的集群只能处理10k/s的文档，无论队列是100或10万，你的集群仍然只能处理10k/s的文档。
队列简单的隐藏的性能问题，同时它将带来数据丢失的风险。任何东西在队列中被定义为将被处理，如果节点宕机，所有请求永远丢失。此外，队列吃了很多内存，这不是一个好主意。
优雅的处理积压的队列对你的应用来说是更好的。当时接收到批量拒绝时，你应该尝试以下操作：
暂停线程3-5秒。
提取被拒绝的批量请求。
发送被拒绝的批量请求。
如果继续被拒绝请重复第1步。
使用次过程，你的代码自然会适应集群的负载，然后正常的退出。
拒绝并不是错误，只是意味着你应该晚点重试:)
有十几个线程池。但大部分可以忽略，仅有几个需要我们关注：
indexing
正常的索引请求
bulk
批量请求，和零散的索引请求完全不同
get
Get-by-ID 操作
search
所有的搜索和查询请求
merging
专注于管理lucene合并