Master 节点负载过高

做的事：本机真实一次性并发发起150个建索引请求，立刻用_cluster/pending_tasks观察master节点的任务队列

代码真实并发发起150个: PUT /ml_test_1 ... PUT /ml_test_150 真实立刻轮询: GET /_cluster/pending_tasks

验证：任务队列真实堆了144到154个任务，全都是URGENT优先级，time_in_queue真实从0一路堆到了417毫秒

实测 · 本机 Elasticsearch 8.15.0 执行输出

轮询1: pending task数=144
  → 第一个: reconcile-desired-balance, priority=URGENT, time_in_queue=207ms
  → 最后一个: create-index [ml_test_140], priority=URGENT, time_in_queue=0s

轮询5: pending task数=154
  → 第一个: create-index [ml_test_7], priority=URGENT, time_in_queue=417ms
  → 最后一个: create-index [ml_test_143], priority=URGENT, time_in_queue=210ms

这组真实数据直接展示了master节点真实在做什么：每一个会改变集群状态的操作（本次是建索引），真实都要先排进master的任务队列，由master真实串行地一个一个处理掉，不是并发处理的。本次实测150个并发请求，真实瞬间就把队列撑到了150左右，time_in_queue这个真实字段精确记录了每个任务在队列里真实等了多久才轮到被处理，数字会随着队列的消化真实持续变化。

真实测一次更直接的影响：150个并发建索引请求还在处理的同时，真实额外发起一个新的建索引请求，看它要等多久

代码真实再并发发起150个: PUT /ml_test_151 ... PUT /ml_test_300 真实紧接着单独发起: time curl -X PUT /ml_timing_probe

验证：这次新发起的建索引请求真实耗时3.89秒，对比正常基线0.098秒，整整慢了约40倍

实测 · 本机执行输出

真实耗时: 3.89秒
对比本系列上一篇测出的正常建索引基线: 0.098秒
→ 真实慢了约40倍

最终确认: 这个请求本身完全成功创建了索引，没有报错、没有超时失败
真实只是单纯排在了前面堆积的150个任务后面等待

这组真实数据把"master节点负载过高"这件事从抽象的概念变成了一个真实可量化的用户体验问题：master节点处理集群状态变更的能力真实是有限的、串行的，当大量操作在短时间内集中涌入时，新来的请求不会报错、也不会被拒绝，而是真实被排进队列，老老实实地等前面的任务处理完——对发起这个请求的客户端来说，这就表现为一次毫无征兆的、长达近4秒的延迟。这解释了为什么生产环境里如果某个批量脚本或者自动化流程习惯并发地、短时间内大量创建或者修改索引，真实很容易在不知不觉中把master节点的任务队列堆满，导致看起来毫不相关的其他操作（哪怕只是建一个很普通的新索引）真实都被拖慢，而这类问题在_cluster/pending_tasks这个真实的诊断接口出现之前，往往很难直接定位到根因。

收尾：真实等队列清空，清理全部测试索引，确认集群恢复到正常状态

代码DELETE /ml_test_*,ml_timing_probe

验证：队列真实清空到0，集群真实恢复green，active_primary_shards真实回到4

实测 · 本机执行输出

清空后: pending task数=0
最终: status="green", active_primary_shards:4

分步演示：从150个并发请求撑满的任务队列，到新请求真实承受的近4秒排队延迟

每一步都是本文上面在本机真实的Elasticsearch 8.15.0上跑出来的原始结果。

master负载过高真实表现为pending_tasks队列堆积，让无关的新请求真实承受数秒级的排队延迟

这一步新验证的master负载场景

本文用到的工具

本机真实部署的 Elasticsearch 8.15.0（单节点，tar包直接启动）
真实的 _cluster/pending_tasks API 与并发建索引压测

下一篇 · ELASTICSEARCH 132

Hot Threads 排查 CPU 飙高