GET _cat/thread_pool/write?v&h=node_name,active,queue,rejected
PUT orders/_settings
{"index": {"number_of_replicas": 1}}
大促开始十分钟,写入错误率到 18%,报 es_rejected_execution_exception: rejected execution of coordinating operation。write 线程池的 queue 一直是 1000。先别急着动参数,把报错原文和时间点记下来,顺序反了容易白折腾。
原因不复杂,write 线程池队列满了就拒绝,不会无限排队。拒绝说明进入速度超过单节点能处理的量,加副本不解决写入,只有加主分片或加节点才提升并行度。上游没有背压,重试还会把压力放大。
这次卡住的地方就在「写入拒绝 429」这一环,单独把它拎出来验证,别和其他改动混在同一次发布里。备份不是备了就行,恢复一次才算数,很多备份文件打开才发现是空的。
接口问题先分清是没发出去、发出去了没收到,还是收到了处理失败。
处理上按这个顺序:先在客户端做限流和指数退避 别原地重试;确认主分片数是否够 单个主分片只能用一个核;临时加节点并让分片重新平衡;长期把批量写改成固定大小 别一次几千条打到同一节点。
改完只确认一件事:rejected 计数不再增长,写入错误率回到 0.1% 以下,queue 稳定在 100 以内。
