环境：
1、aws的es,版本7.1.1
2、单节点8核64G,集群有3个节点
3、目前只有一个业务index,该index有5个分片，1个replication。目前doc数量340万，store.size为3G,pri.store.size为1.6G
4、业务查询语句比较复杂，但是正常查询的时候耗时在30ms左右
5、服务器节点各个线程池基本保持默认大小设置，只是修改率搜索线程池的大小为13（根据文档的要求8*3/2+1）
现象：
1、平常场景下，最大qps按160计算，es的cpu使用率保持在25%一下，比较稳定；
2、当晚上某个业务高峰期，qps到达1000时，cpu使用率到达90%，比较危险。
3、在最顶点的时候，搜索线程池13个线程满载，队列等待执行任务680.
4、es监控
问题：
1、个人感觉这个es的配置很高了，为啥qps才1000就扛不住了？
2、es监控jvm内存压力都比较小，为啥cpu确这么高？不应该是同步增长的吗？
3、主要想定位cpu这么高的原因然后有解决方案
1、aws的es,版本7.1.1
2、单节点8核64G,集群有3个节点
3、目前只有一个业务index,该index有5个分片，1个replication。目前doc数量340万，store.size为3G,pri.store.size为1.6G
4、业务查询语句比较复杂，但是正常查询的时候耗时在30ms左右
5、服务器节点各个线程池基本保持默认大小设置，只是修改率搜索线程池的大小为13（根据文档的要求8*3/2+1）
现象：
1、平常场景下，最大qps按160计算，es的cpu使用率保持在25%一下，比较稳定；
2、当晚上某个业务高峰期，qps到达1000时，cpu使用率到达90%，比较危险。
3、在最顶点的时候，搜索线程池13个线程满载，队列等待执行任务680.
4、es监控
问题：
1、个人感觉这个es的配置很高了，为啥qps才1000就扛不住了？
2、es监控jvm内存压力都比较小，为啥cpu确这么高？不应该是同步增长的吗？
3、主要想定位cpu这么高的原因然后有解决方案
3 个回复
tulong - 80 IT
赞同来自:
zqc0512 - andy zhou
赞同来自:
分片、负载均衡节点。
byx313 - BLOG:https://www.jianshu.com/u/43fd06f9589c
赞同来自:
有点儿凶残
不过为什么要用模糊匹配呢，怕分词以后不满足你们的查询？