解读

国内生产环境常把 CouchDB 当“离线优先”数据中心，节点数一旦上去，httpd 线程池、文件描述符、BEAM 虚拟机调度都可能成为瓶颈。
“throttle”并不是官方指标名，而是**“因并发连接或资源不足导致请求被延迟、复用甚至拒绝”的统称。
面试时，考官想听你如何把 /_stats/httpd 里的瞬时计数器与斜率变化结合起来，给出可落地的告警规则**，而不是背文档。

知识点

1. httpd 段核心字段
   • open_requests：当前正在处理的请求数，包含等待 BEAM 调度的。
   • requests.count & requests.value：累计已完成的请求，可算 QPS。
   • aborted_requests：客户端超时或主动断开，突增即 throttle 信号。
   • clients_active：已建立 TCP 连接但尚未发送完整 HTTP 报文的数量，持续高于 max_connections×0.8 就危险。
   • pending_updates：等待写盘的数据库更新，>200 且持续 30s 即可认为写路径被 throttle。
2. 阈值经验（国内 4C8G 节点，默认 max=8192）
   • open_requests > 5000 且 aborted_requests 增长率 > 10%/min → 触发 throttle。
   • clients_active 占 max_connections 比例 > 85% → 即将触发。
3. 斜率比绝对值更敏感：用 (current-open_requests - 5s 前)/5s 得到排队加速度，>200/s 立即扩容或限流。
4. 必须结合 system 段：erlang_memory.total 超过物理内存 70% 时，上述阈值下调 30%。

答案

1. 定时 GET /_stats/httpd，取 open_requests、aborted_requests、clients_active、pending_updates 四个值。
2. 计算两条衍生指标：
   a) 排队加速度 = (open_requests_now − open_requests_5s_ago) / 5
   b) abort 增长率 = (aborted_requests_now − aborted_requests_5s_ago) / aborted_requests_5s_ago ×100%
3. 判定规则（任一满足即 throttle）：
   • open_requests > 5000 且 abort 增长率 > 10%/min
   • clients_active > max_connections×0.85
   • 排队加速度 > 200/s 持续 3 个周期
4. 发现 throttle 后，优先纵向扩容 BEAM max_ports，其次横向加节点并调低 replication 并发，而非盲目调大 httpd 线程池。

拓展思考

1. 国内公有云常把负载均衡空闲超时设为 60s，若 aborted_requests 突增但 clients_active 不高，先查SLB 超时而不是 CouchDB 本身。
2. 对写重场景，可再监控 /_stats/couch_log/level_error 是否出现**“emfile”** 或**“too_many_files”**，与 httpd 指标交叉验证。
3. 若集群启用了 nouveau 或 dreyfus 全文索引，search 请求也会走 httpd，需把 search 端口流量剥离后再看阈值，避免误报。