Elasticsearch集群中JVM问题的应对之策.docVIP

Elasticsearch集群中JVM问题的应对之策 5 我是谁 个推 首席搜索架构师 卞泽鑫. 主要职责： ??前沿技术研究 ??平台架构设计与开发 演讲提纲 ?? 个推基于Elasticsearch的搜索引擎架构 ?? JVM在个推Elasticsearch集群的问题分析 ?? JVM在个推Elasticsearch集群中的调优 大家都在用个推 在第三方推送市场，个推占有率90% ?? SDK接入用户超过50亿(海外5亿) ?? 接入应用超过35万 ?? 开发者人数超过20万 ?? 独立覆盖8亿手机终端(海外1亿) ?? 日均活跃用户近6亿 ?? 同时在线超过3亿 个推搜索引擎架构 Master-Data-LoadBalance Elasticsearch 集群 Master-Data Elasticsearch 集群 Solr 单节点 9 个推Elasticsearch演变 ?? 第一个Elasticsearch使用版本：0.20.6 ?? Index-Source分离架构使用的Elasticsearch版本：0.90.10 ?? 第一个Elasticsearch1.0以上的正式版本：1.2.2 ?? 目前使用的Elasticsearch版本：1.5.2 个推Elasticsearch踩过的坑 ?? 建立索引(index)慢 ?? Elasticsearch节点脱离集群 ?? Elasticsearch的get阻塞 ?? Elasticsearch备份无法恢复 个推Elasticsearch集群JVM分析工具 ?? gc日志输出 ??jconsole ??jvisualvm ??jstack ??Eclipse内存分析器(eclipse memory analyzer) 个推Elasticsearch集群JVM问题分析 ?? [es-date-1224] [gc][young][3402090][244044] duration [887ms],collections [1]/[1.5s], total [887ms]/[3.3h], memory [4.5gb]-gt;[4gb]/[6.9gb],all_pools {[young] [499.4mb]-gt;[782.8kb]/[532.5mb]}{[survivor][32.7mb]- gt;[30.2mb]/[66.5mb]}{[old] [3.9gb]-gt;[3.9gb]/[6.3gb]} ?? 上面这个例子的情况无须紧张，只是young gc，并且只用了887ms，对 于Elasticsearch而言，没有啥影响。唯一需要留心的是，如果在日志中 出现连续的和长时间的young gc，则需要引起警觉，可能是你的Heap内 存分配不够。 个推Elasticsearch集群JVM问题分析 ?? [es-data-1224] [gc][old][76581][22] duration [3.1m], collections[2]/[3.1m], total [3.1m]/[3.1m], memory [3gb]-gt;[1.2gb]/[3.4gb], all_pools{[young] [251mb]-gt;[74.9mb]/[266.2mb]}{[survivor][25.8mb]-gt;[0b]/[33.2mb]}{[old] [2.8gb]-gt;[1.1gb]/[3.1gb]} ?? 如果这种JVM出现，则你的节点一定被踢出了集群。old gc是比较耗时， 上面这个例子用了3.1分钟，一定是出了啥大事，要不是然“世界”不会 停转这么久的，呵呵！ 个推Elasticsearch集群JVM问题分析 节点频繁GC，节点丢失 调大参数 ?? discovery.zen.fd.ping_interval ?? discovery.zen.fd.ping_timeout ?? discovery.zen.fd.ping_retries 15 个推Elasticsearch集群JVM问题分析 客户端建立索引很慢，但是从监控上看到ES的load并不高 个推Elasticsearch集群JVM问题分析 客户端JStack分析，客户端实际上是阻塞的 个推Elasticsearch集群JVM问题分析 从ES的jstack信息的分析结果来看，应该是flush操作导致ES建索引慢 index.translog.flush_threshold_ops ＝ 5000 ndex.translog.flush_threshold_size ＝ 200mb 个推Elasticsearch集群JVM问题分析 表现：Elasticsearch集群get操作缓慢 个推Elasticsear