/health/ready flaps 到 503 pool_metadata_check_timeout 在健康节点上 — 100 毫秒的互斥锁检查超时被报告为未准备就绪

描述错误

在 1.0.0 中,健康节点上的 /health/ready 会在 300 毫秒内间歇性地响应 503，并附带 degradedReasons: ["pool_metadata_check_timeout"]。每分钟大约会发生一次，节点上没有池元数据活动。原因字符串说明了发生的情况：准备处理程序等待了 100 毫秒，池元数据保存门锁互斥量，等待已过期，准备处理程序报告节点不准备。节点没有问题 — 写入正常进行，集群快照中写入门锁读取 writable，前后的集群快照中都读取 writable，下一个 200 毫秒的采样结果仍为 200。我们发现这个问题是因为负载均衡器在每个节点上都会检查 /health/ready（HAProxy httpchk，4 个代理 × ~2 秒的间隔），并在从 1.0.0-rc.5 版本升级后以不定期的间隔记录一组 HEAD /health/ready → 503。在两个后续节点上，每 5 Hz 的采样器显示了形状（只记录非 200 的样本和第一个恢复样本）：

# object04（后续节点，没有扫描器工作，大约 17 个 80 个核心中的 17 个正在使用）
20:56:25.630 503 ["pool_metadata_check_timeout"]
20:56:25.937 200
20:56:30.479 503 ["pool_metadata_check_timeout"]
20:56:30.785 200
20:56:45.439 503 ["pool_metadata_check_timeout"]
20:56:45.746 200
20:56:59.390 503 ["pool_metadata_check_timeout"]
20:56:59.733 200

在整个 40 分钟的运行期间（2026-09-16 20:56:13–21:36:13 CST），object03 产生了 16 个这样的中断，object04 产生了 27 个，每个持续 0.31–0.34 秒（100 毫秒的预算加上 200 毫秒的采样间隔），每个只包含 pool_metadata_check_timeout，每个都通过下一个样本恢复。它是稳定状态，不是升级过渡：四小时后（2026-09-17 00:51–00:54 CST，通过 HTTPS 采集 900 个 5 Hz 的样本）在 object04 上产生了 4 个，原因相同，形状相同。速率与管理员流量无关：对同一节点发出 40 次经过身份验证的管理员请求（10 次 cluster/snapshot，10 次 scanner/status，5 次 storageinfo，3 次 info）期间或之后，没有出现任何超时。