说明
本文描述问题及解决方法同样适用于 腾讯云 Elasticsearch Service(ES)。
本文延续:Elasticsearch集群出现负载不均的问题如何解决
背景
ES集群在某些情况下会出现CPU使用率高的现象,具体有两种表现:
1. 个别节点CPU使用率远高于其他节点;
2. 集群中所有节点CPU使用率都很高。
本篇文章我们着重讲解第二种情况。
问题现象
集群所有节点CPU都很高,但读写都不是很高。
图中可以看到,kibana端Stack Monitoring的监控,CPU使用率每个节点都很高。
原因
出现这种情况,由于表面上看集群读写都不高,导致很难快速从监控上找到根因。所以需要细心观察,从细节中找答案,下面我们介绍几种可能出现的场景以及排查思路。
原因一:比较大的查询请求导致CPU飙高
这种情况比较常见,细心一点的话可以从监控上找到线索:
从监控上可以发现,查询请求量的波动与集群最大CPU使用率是基本吻合的。 发现了问题所在,进一步确认则需要开启集群的慢日志收集,可以参考官方文档:集群日志说明。从慢日志中,我们可以得到更多信息。比如引起慢查询的索引、查询参数以及内容。
解决方案
针对这种情况,我们一般建议: 1. 尽量避免大段文本搜索,优化查询; 2. 通过慢日志确认查询慢的索引,对于一些数据量不大的索引,设置少量分片多副本,比如1分片多副本,以此来提高查询性能;
3. 考虑集群升配扩容。
原因二:写入请求导致CPU飙高
同理,首先通过监控来观察到CPU飙高是与写入相关,然后开启集群的慢日志收集,确认写入慢的请求,进行优化。也可以通过获取hot_threads
信息来确认什么线程在消耗CPU:
curl http://9.15.49.78:9200/_nodes/hot_threads
比如这里发现的是有大量ingest pipeline操作,ingest操作是十分消耗资源的。
解决方案
如遇到上面这种问题,则需要业务方根据实际情况来优化。
原因三:Segment过多
当segment过多时,索引的性能会变得很差。
解决方案
在业务低峰期进行强制合并操作,减少segment数量,具体请参见force merge,该操作也会将缓存中的delete.doc彻底删除,将小segment合并成大segment。
小结
排查该类问题的关键点,还是在于善用集群的监控指标来快速判断问题的方向,再配合集群日志来定位问题的根因,才能快速地解决问题。