关于 Elasticsearch 不同分片设置的压测报告
2023-02-15
摘要 #
为了验证当前集群经常出现索引超时以及请求拒绝的问题,现模拟线上集群环境及索引设置,通过压测工具随机生成测试数据,针对当前的 850 个分片的索引,以及减半之后的索引,以及更小分片索引的写入进行压测,使用不同的并发、不同的批次大小来观察索引的吞吐情况,并记录写入队列的堆积情况,用来分析分片数、批次数对写入的影响,从而确定后续的优化方案。
压测场景 #
Elasticsearch 版本 v7.7.1, 共有 57 个节点,其中 3 个独立 Master,3 个协调节点,31GB JVM。
压测流程 #
单索引 850 分片 #
运行测试 #
开启 gzip 流量压缩,执行压测:
root@loadgen:/opt/loadgen# ./loadgen-linux-amd64 -config loadgen.yml -d 6000 -c 100 -compress
1 副本 100 并发 #
0 副本 100 并发 #
0 副本 200 并发 #
写入队列已经存在大量堆积和拒绝的现象了:
1 副本 200 并发 #
1 副本 400 并发 #
1 副本 800 并发 #
1 副本批次 500 并发 100 #
1 副本批次 2000 并发 100 #
1 副本批次 5000 并发 100 #
1 副本批次 5000 并发 200 #
单索引 425 分片 #
1 副本批次 50 并发 100 #
1 副本批次 50 并发 200 #
1 副本批次 50 并发 400 #
1 副本批次 50 并发 800 #
1 副本批次 500 并发 100 #
1 副本批次 2000 并发 100 #
1 副本批次 5000 并发 100 #
单索引 50 分片 #
1 副本批次 50 并发 100 #
1 副本批次 500 并发 100 #
1 副本批次 1000 并发 100 #
1 副本批次 5000 并发 100 #
走网关单索引 425 分片 #
1 副本批次 50 并发 400>200 #
1 副本批次 500 并发 100 #
1 副本批次 500 并发 200 #
1 副本批次 500 并发 400 #
1 副本批次 5000 并发 100 #
1 副本批次 5000 并发 200 #
1 副本批次 5000 并发 400 #
走网关单索引 850 分片 #
1 副本批次 50 并发 400 #
1 副本批次 500 并发 400 #
1 副本批次 5000 并发 400 #
压测结果 #
索引数 | 分片数 | 副本数 | 批次大小 | 压测并发 | 平均写入吞吐(eps) |
---|---|---|---|---|---|
1 | 850 | 1 | 50 | 100 | 10,000 |
1 | 850 | 0 | 50 | 100 | 30,000 |
1 | 850 | 0 | 50 | 200 | 40,000 |
1 | 850 | 1 | 50 | 200 | 18,000 |
1 | 850 | 1 | 50 | 400 | 27,500 |
1 | 850 | 1 | 50 | 800 | 29,700 |
1 | 850 | 1 | 500 | 100 | 30,187 |
1 | 850 | 1 | 2000 | 100 | 68,000 |
1 | 850 | 1 | 5000 | 100 | 98,915 |
1 | 850 | 1 | 5000 | 200 | 78,462 |
1 | 425 | 1 | 50 | 100 | 12,695 |
1 | 425 | 1 | 500 | 100 | 46818 |
1 | 425 | 1 | 2000 | 100 | 100,000 |
1 | 425 | 1 | 5000 | 100 | 130,000 |
1 | 50 | 1 | 50 | 100 | 32,987 |
1 | 50 | 1 | 500 | 100 | 96,207 |
1 | 50 | 1 | 1000 | 100 | 147,719 |
1 | 50 | 1 | 5000 | 100 | 156,961 |
走网关节点异步合并模式:
索引数 | 分片数 | 副本数 | 批次大小 | 压测并发 | 平均写入吞吐(eps) |
---|---|---|---|---|---|
1 | 425 | 1 | 50 | 100 | 500 |
1 | 425 | 1 | 50 | 200 | 1,000 |
1 | 425 | 1 | 50 | 400 | 2,000 |
1 | 425 | 1 | 500 | 100 | 4,800 |
1 | 425 | 1 | 500 | 200 | 9,350 |
1 | 425 | 1 | 500 | 400 | 17,000 |
1 | 425 | 1 | 5000 | 100 | 50,000 |
1 | 425 | 1 | 5000 | 200 | 100,000 |
1 | 425 | 1 | 5000 | 400 | 175,000 |
1 | 850 | 1 | 50 | 400 | 2000 |
1 | 850 | 1 | 500 | 400 | 18,800 |
1 | 850 | 1 | 5000 | 400 | 137,000 |
结论 #
大分片索引,850 或者 425,在并发即使只有 100 的情况下就有可能出现占满线程池,出现请求拒绝的情况,单个批次的文档数比较小的情况下,更容易出现。 而同样格式的索引,在 50 个分片的情况下,索引的吞吐是 425 分片的两倍,850 分片的三倍,且线程池基本上没有堆积,或者堆积很快处理完。单次请求的文档数越多,写入的效率越高。 某些场景下索引分片虽然做了 Routing 处理,但是超大分片索引存在严重的转发效率问题,建议按照业务维度,或者当前的 Routing 维度进行索引的划分,将超大索引拆分成若干个子索引,单个索引的分片数尽量不要超过 20 个。