摘要

为了验证当前集群经常出现索引超时以及请求拒绝的问题，现模拟线上集群环境及索引设置，通过压测工具随机生成测试数据，针对当前的 850 个分片的索引，以及减半之后的索引，以及更小分片索引的写入进行压测，使用不同的并发、不同的批次大小来观察索引的吞吐情况，并记录写入队列的堆积情况，用来分析分片数、批次数对写入的影响，从而确定后续的优化方案。

压测场景

Elasticsearch 版本 v7.7.1, 共有 57 个节点，其中 3 个独立 Master，3 个协调节点，31GB JVM。

压测流程

单索引 850 分片

展开查看索引定义

展开查看样例数据

展开查看loadgen 配置

运行测试

开启 gzip 流量压缩，执行压测：

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

压测结果

走网关节点异步合并模式：

结论

大分片索引，850 或者 425，在并发即使只有 100 的情况下就有可能出现占满线程池，出现请求拒绝的情况，单个批次的文档数比较小的情况下，更容易出现。 而同样格式的索引，在 50 个分片的情况下，索引的吞吐是 425 分片的两倍，850 分片的三倍，且线程池基本上没有堆积，或者堆积很快处理完。单次请求的文档数越多，写入的效率越高。 某些场景下索引分片虽然做了 Routing 处理，但是超大分片索引存在严重的转发效率问题，建议按照业务维度，或者当前的 Routing 维度进行索引的划分，将超大索引拆分成若干个子索引，单个索引的分片数尽量不要超过 20 个。