Elasticsearch创建新文档过慢 多线程耗时线性上涨问题咨询

问题根因说明 #

你遇到的耗时线性上涨不是ES串行处理请求，而是单条写入模式+参数配置不合理导致的并发写入瓶颈，可按以下优先级调整：

1 优先调整写入模式 #

你当前使用单条/_doc接口写入是效率最低的方式，每条请求都要走完整的认证、参数解析、索引计算、磁盘刷盘全流程，多线程并发下会快速打满ES写入队列，导致请求排队耗时线性增长。

• 替换为ES批量写入接口/_bulk，每次批量提交的文档总大小控制在5_{15MB，对应文档数量根据单条大小控制在1000}5000条即可，写入效率比单条提交高5~20倍。

2 调整ES索引侧写入配置 #

全量数据导入阶段可以临时调整以下索引配置，导入完成后再恢复到业务需要的参数即可：

• 关闭实时刷新：将index.refresh_interval设置为-1，避免高频生成段文件带来的额外开销，全量写入完成后改回业务需要的刷新间隔（默认1s）
• 临时关闭副本：将index.number_of_replicas设置为0，写入阶段跳过副本同步开销，写入完成后再调整为需要的副本数
• 调整事务日志刷盘策略：将index.translog.durability设置为async，index.translog.sync_interval设置为30s，避免每次写入请求都等待磁盘刷盘
• 检查写入线程池状态：调用GET /_cat/thread_pool/write?v查看是否有拒绝的请求，如果rejected列数值大于0，可适当调大thread_pool.write.queue_size参数（建议最大不超过2000，避免内存溢出）

3 客户端侧配置优化 #

• 复用HTTP连接：C#侧必须使用单例HttpClient，不要每次请求新建实例，避免多线程下反复创建HTTP连接的开销
• 控制并发数：ES写入吞吐量不会随客户端线程数线性增长，客户端并发数控制在「ES节点数 * CPU核心数 * 2」即可，过高的并发只会导致请求在ES端排队，徒增耗时

4 分片配置的正确逻辑 #

如果你的ES是单节点部署，调整分片数不会有任何收益，单节点无法利用分布式并行写入能力，单节点场景下分片数设置为CPU核心数的1~2倍即可，过多分片只会增加元数据管理开销。

内容的提问来源于stack exchange，提问作者小小虾米