error_log 不直接记录进程调度延迟，但通过 worker 无响应、upstream 超时、accept 失败等间接现象暴露调度问题；需结合 pidstat/perf 等工具交叉验证才能准确定位。
error_log 本身不直接记录进程调度延迟，它也不是为诊断 CPU 调度、内核抢占或 worker 进程排队等待 CPU 时间片这类底层系统级延迟而设计的。但它在分析与调度延迟强相关的 Nginx 行为异常时，能提供关键间接线索——前提是日志级别设置得当、位置配置合理。
? error_log 如何间接暴露调度延迟问题
Nginx 的 event loop 是单线程（每个 worker 进程内）协作式运行的。当 worker 进程因长时间占用 CPU（如复杂 Lua 脚本、正则回溯、阻塞 I/O）、或系统整体 CPU 过载导致调度滞后时，Nginx 自身不会打印“调度延迟 X ms”，但会表现出一系列可被 error_log 捕获的副作用现象：
worker process is not responding（crit 级）
当 master 检测到某个 worker 超过worker_shutdown_timeout（默认 0，即不检测）或通过信号机制发现 worker 长时间无响应时触发。这常是 CPU 饱和 + 调度延迟的典型结果。upstream timed out (110: Connection timed out)或upstream prematurely closed connection（warn/error 级）
如果后端健康、网络正常，但大量请求在 upstream 阶段超时，且access_log中request_time显著大于upstream_response_time，说明 Nginx 自身处理（如 rewrite、proxy_pass 前逻辑）耗时异常——背后可能是 worker 被延迟调度，无法及时发起或接收 upstream 数据。accept() failed (23: Too many open files)或accept() failed (11: Resource temporarily unavailable)（alert/warn 级）
这类错误高频出现，往往不是文件描述符真用尽，而是 accept 队列积压 → worker 处理跟不上 → 新连接被丢弃。根本原因常是 worker 因调度延迟无法及时调用accept()，尤其在高并发短连接场景下。signal 17 (SIGCHLD) received后伴随大量reconfiguring或gracefully shutting down日志（notice 级）
若 reload 频繁失败或 worker 重启异常，可能反映系统负载过高、调度器无法及时分配资源给新 worker 进程。
✅ 关键点：这些日志条目本身不等于“调度延迟”，但当它们集中爆发、时间戳密集、且与
top/pidstat -w显示的cswch/s（上下文切换）或nvcsw/s（非自愿切换）飙升同步出现时，就是强相关证据。
?️ 怎么让 error_log 更有效地辅助判断？
设为
warn或更高（如临时error），避免漏掉前置预警crit和alert级别才记worker process is not responding；warn才记upstream timeout的完整上下文。error级反而可能过滤掉关键 warning。在
http或server块中单独配置error_log，并启用debug（仅限排查期）debug级可输出event timer del,event timer add,epoll wait等事件循环细节。若看到epoll wait返回后长时间无后续accept/recv日志，说明事件处理被卡住——此时结合perf sched record可确认是否为调度延迟。配合
access_log中$request_time和$upstream_response_time对比
若request_time持续 > 500ms，而upstream_response_time< 10ms，差值部分大概率是 Nginx 自身处理延迟，再查error_log是否同期有 warn/error，就能交叉定位。
⚙️ 更直接的调度延迟诊断工具（需搭配 error_log 使用）
| 工具 | 作用 | 关联 error_log 的方式 |
|---|---|---|
pidstat -w -p $(pgrep nginx) 1 |
查看 Nginx worker 的每秒上下文切换数（cswch/s）和非自愿切换（nvcsw/s） |
nvcsw/s 高 → 进程频繁被抢占 → 查 error_log 是否有超时、accept 失败等连锁报错 |
perf sched record -p $(pgrep nginx) → perf sched latency
|
分析 worker 进程调度延迟分布 | 发现毫秒级延迟后，回查该时间段 error_log 中是否有对应错误爆发 |
cat /proc/$(pgrep nginx)/status \| grep -E "voluntary_ctxt_switches|nonvoluntary_ctxt_switches" |
快速查看累计切换次数 | 数值突增时段，对照 error_log 时间戳找共性 |
✅ 小结
error_log 不是调度延迟的“测量仪”，而是它的“症状记录本”。它不能告诉你“CPU 调度延迟了 12.3ms”，但能告诉你：“这个 worker 刚被 kill，因为卡住了”、“所有 upstream 请求都在 60s 后超时”、“accept 队列满了一整分钟”。把这些信号和系统级指标对齐，才能准确定位调度瓶颈。
真正要确认调度问题，必须 error_log + pidstat/perf + dmesg（查 OOM killer 或 soft lockup）三者联动。单看日志，永远只是拼图的一角。
