Selection ES集群20250415压测报告（esperf）

一、背景

Selection Elasticsearch 集群为解决上下文游标BUG升级至7.7.1版本后，需要摸清与7.6.2的性能差异。

ES 版本

7.7.1

压测目的

1. 加大压测力度，测出该集群的性能基线

压测 范围

Selection ES集群6台主机，配置16C/32G内存/200G磁盘，IP地址如下：

集群地址：
172.25.162.36
172.25.162.38
172.25.162.39
172.25.162.41
172.25.162.44
172.25.162.46

三、压测使用场景

1. 压测的查询语句

[Selection ES 压测语句]lue

2. 压测用到的索引参考

索引	分片数	副本数	文档数	存储空间
sph_store_takeout_yumc_ks_20250414_2249	1	5	35014	370.3mb
sph_merchant_yumc_ks_20250415_0405	1	5	652	477.7kb

3. 时间段

共测试2个场景下，15号的2个时间段14:25开始，15:35开始。

四、压测结果对比

1. 第一次压测（14:25左右）

• 使用sph_store_takeout_yumc_ks_20250414_2249进行压测。
• CPU使用率

• QPS

• 任务队列

• 网络IO

• 集群平均查询耗时（query）

2. 第二次压测（15:35左右)

• 使用sph_store_takeout_yumc_ks_20250414_2249，sph_merchant_yumc_ks_20250415_0405做混合压测。混合时间段为15:45-16:05左右。
• CPU使用率

• QPS

• 任务队列

• 网络IO

• 集群平均查询耗时（query）

3. 压测数据对比

7.7.1版本压测数据

压测记录	查询索引平均存储大小	集群数据量	索引数量	分片数量	每秒查询量（QPS）	内存利用率	CPU 利用率	磁盘利用率	网络带宽使用	GC延迟时间	查询响应时间	线程池队列情况
第一次压测	370MB	7.97GB	12	72	51K	66%	96%	1%	140MB	9ms	665us	281
第二次压测	477KB	7.97GB	12	72	86.9K	66%	50%	1%	17.3MB	2ms	845us	11

7.6.2版本压测数据

压测记录	查询索引平均存储大小	集群数据量	索引数量	分片数量	每秒查询量（QPS）	内存利用率	CPU 利用率	磁盘利用率	网络带宽使用	GC延迟时间	查询响应时间	线程池队列情况
第一次压测	3.9MB	2.45GB	25	146	96K	66%	96%	7%	23MB	6.37ms	665us	36
第二次压测	347.3MB	2.45GB	25	146	31K	66%	91%	7%	177MB	7.08ms	845us	31
第三次压测	347.3MB	2.45GB	25	146	30K	66%	93%	7%	137MB	8.07ms	1.73ms	83
第四次压测	98.5MB	2.45GB	25	146	76K	66%	90%	7%	153MB	6.2ms	542us	38

五、压测分析

1. 第一次压测使用sph_store_takeout_yumc_ks_20250414_2249这个文档进行测试。qps最高达51K时，单台机器cpu使用率到96%，线程池队列为最高至280左右，平均80，判断已达瓶颈。
2. 第二次压测使用sph_merchant_yumc_ks_20250415_0405进行压测，qps最高达86.7K时，单台机器cpu使用率到50%，线程池队列<10。增加esperf进程查询sph_store_takeout_yumc_ks_20250414_2249，目的是提高集群cpu使用率及qps，但增加esperf进程后，qps表现为降低。观察到拨测机CPU已满载，拨测机在进行小文档拨测时无法创建更多的连接请求，无法定位到在执行小索引查询时的性能基线。

六、结论

1. 根据现有的压测报告可以观察到，qps与索引大小存在关联。查询的索引更大时，集群的qps表现更低。在进行350MB的索引查询时，7.7.1集群性能相较于7.6.2有较为明显提升（QPS 31K --> 51K）。在小文档查询时，虽未测出集群性能基线，但7.7.1版本在CPU占用为50%时就达到了87K的qps，可以预估出在CPU满载时qps>100K。也有较为明显的性能提升。

参考资料

[Selection ES集群7月24日压测报告]lue