本文描述问题及解决方法同样适用于 腾讯云 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：
代码语言：javascript
复制
代码语言：javascript复制curl http://9.15.49.78:9200/_nodes/hot_threads
比如这里发现的是有大量ingest pipeline操作，ingest操作是十分消耗资源的。
解决方案
如遇到上面这种问题，则需要业务方根据实际情况来优化。
原因三：Segment过多
当segment过多时，索引的性能会变得很差。
解决方案
在业务低峰期进行强制合并操作，减少segment数量，具体请参见force merge，该操作也会将缓存中的delete.doc彻底删除，将小segment合并成大segment。
小结
排查该类问题的关键点，还是在于善用集群的监控指标来快速判断问题的方向，再配合集群日志来定位问题的根因，才能快速地解决问题。
