不能通过调优 timer_resolution 降低时间获取开销——它反而增加 clock_gettime() 调用频次和上下文切换；其真实作用是提升长连接超时检查灵敏度，仅适用于 WebSocket 等低流量长连接场景。
不能通过配置 timer_resolution 指令来降低 Nginx 内部频繁获取系统时间戳带来的高频路径调度开销——它恰恰会增加该开销。
这个指令的设计目标不是“减少时间读取”，而是提升超时检查的精度与响应速度，其代价是更频繁地调用 clock_gettime(CLOCK_MONOTONIC)，从而引发更多用户态到内核态的切换和 CPU 时间片调度。
timer_resolution 实际如何影响时间读取频率
-
未配置时（默认行为）：
Nginx 只在必要时刻读取一次系统时间，例如：- epoll_wait 返回后
- 收到信号（如 SIGALRM）
- 定时器到期或连接状态变更
读取结果会被缓存复用，避免重复系统调用。
配置为
timer_resolution 100ms时：
Nginx 强制每 100ms 主动唤醒 worker 进程，调用clock_gettime()更新内部时间缓存，并遍历检查所有待超时连接。设为
timer_resolution 1ms或0时：
几乎每个事件循环都触发一次高精度时钟读取，上下文切换陡增，CPU 的%sy（系统态）使用率明显上升。
所以：它不降低系统调用频次；它直接提高
clock_gettime()调用密度；它增加的是单个 worker 进程内部的调度压力，而非网络 I/O 或连接分发层面的开销。
哪些配置能真正减少时间相关调度开销
如果你观察到 CPU 系统态偏高、strace 显示大量 clock_gettime 调用，应优先考虑以下做法：
- 保持
timer_resolution完全不设置（即使用默认行为），这是绝大多数 HTTP 服务的最佳选择； - 缩短
keepalive_timeout（例如从 300s 改为 30s），减少需持续跟踪的空闲连接数； - 关闭非必需的超时项，如
resolver_timeout、client_header_timeout（若业务不依赖动态 DNS 或无特殊头解析逻辑）； - 确保
timer_resolution仅出现在main块中，误放在http或server块会导致配置被静默忽略或报错； - 排查第三方模块是否绕过 Nginx 时间缓存机制，自行高频调用
clock_gettime()。
什么场景下才建议启用 timer_resolution
仅当同时满足以下条件时，才值得接受其额外开销：
- 业务承载大量低流量长连接（如 WebSocket、HTTP/2 Server Push、MQTT 心跳）；
- 对空闲连接断连延迟极其敏感（例如要求在 200ms 内检测并关闭失效心跳）；
- 已实测发现当前超时判断滞后（如
keepalive_timeout 60s，但实际释放延迟达 65s+）； - 可接受约 1%–3% 的额外 CPU 占用作为交换。
此时推荐设为 timer_resolution 100ms，避免低于 10ms（如 1ms 或 0），否则调度负担会急剧上升。
