elasticsearch集群中jvm问题的应对之策

《elasticsearch集群中jvm问题的应对之策》由会员上传分享，免费在线阅读，更多相关内容在教育资源-天天文库。

1、Elasticsearch集群中JVM问题的应对之策Elasticsearch集群中JVM问题的应对之策5我是谁个推首席搜索架构师卞泽鑫.主要职责：??前沿技术研究??平台架构设计与开发演讲提纲??个推基于Elasticsearch的搜索引擎架构??JVM在个推Elasticsearch集群的问题分析??JVM在个推Elasticsearch集群中的调优大家都在用个推在第三方推送市场，个推占有率90%??SDK接入用户超过50亿(海外5亿)??接入应用超过35万??开发者人数超过20万??独立覆盖8亿手机终端(海外1亿)??日均活跃用户近6亿??同时在线超过3亿个推

2、搜索引擎架构Master-Data-LoadBalanceElasticsearch集群Master-DataElasticsearch集群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节点脱离集群??

3、Elasticsearch的get阻塞??Elasticsearch备份无法恢复个推Elasticsearch集群JVM分析工具??gc日志输出??jconsole??jvisualvm??jstack??Eclipse内存分析器(eclipsememoryanalyzer)个推Elasticsearch集群JVM问题分析??[es-date-1224][gc][young][3402090][244044]duration[887ms],collections[1]/[1.5s],total[887ms]/[3.3h],memory[4.5gb]->[4gb

4、]/[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]}??上面这个例子的情况无须紧张，只是younggc，并且只用了887ms，对于Elasticsearch而言，没有啥影响。唯一需要留心的是，如果在日志中出现连续的和长时间的younggc，则需要引起警觉，可能是你的Heap内存分配不够。个推Elasticsearch集群JVM问题分析??[es-d

5、ata-1224][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出现，则你的节点一定被踢出了集群。oldgc是比较耗时，上面这个例子用了3.1分

6、钟，一定是出了啥大事，要不是然“世界”不会停转这么久的，呵呵！个推Elasticsearch集群JVM问题分析节点频繁GC，节点丢失调大参数??discovery.zen.fd.ping_interval??discovery.zen.fd.ping_timeout??discovery.zen.fd.ping_retries15个推Elasticsearch集群JVM问题分析客户端建立索引很慢，但是从监控上看到ES的load并不高个推Elasticsearch集群JVM问题分析客户端JStack分析，客户端实际上是阻塞的个推Elasticsearch集群JVM问题

7、分析从ES的jstack信息的分析结果来看，应该是flush操作导致ES建索引慢index.translog.flush_threshold_ops＝5000ndex.translog.flush_threshold_size＝200mb个推Elasticsearch集群JVM问题分析表现：Elasticsearch集群get操作缓慢个推Elasticsearch集群JVM问题分析个推Elasticsearch集群JVM问题分析通过工具的分析结果，我们可以看到节点服务器的cpu基本全部跑满，主要是因为每次es的get请求的条件都不一样，在ES集群的queryRe