timer_resolution不能降低系统调用频率，反而会提高clock_gettime()调用频次以提升超时检查灵敏度；它通过每100ms（或设定值）强制唤醒并读取高精度时钟，增加上下文切换和CPU开销，仅适用于WebSocket等长连接场景。
不能通过调优 timer_resolution 来降低 Worker 进程向内核请求系统时间的频率——恰恰相反，启用 timer_resolution 会显著提高该频率。
这个参数的设计目的不是“减少时钟读取”，而是让 Nginx 更频繁地读取高精度时钟（如 clock_gettime(CLOCK_MONOTONIC)），从而更及时地判断长连接是否空闲超时。它本质上是用更多次的用户态-内核态切换，换取超时检查的灵敏度。
timer_resolution 实际如何影响时钟读取
- 未配置时：Nginx 在事件循环中仅在必要时（如处理定时器、接收信号、或 epoll_wait 被唤醒后）才读取一次系统时间；时间值会被缓存复用，避免重复调用。
-
配置为
timer_resolution 100ms时：Nginx 强制每 100ms 主动唤醒一次，调用clock_gettime()更新内部时间缓存，并检查所有待超时连接。 -
设为
timer_resolution 1ms或0时：几乎每个事件循环都触发一次时钟读取，CPU 开销和上下文切换明显上升。
所以：
- 它不降低系统时间请求频率；
- 它直接增加
clock_gettime()系统调用次数； - 其代价是轻微但可测的 CPU 占用上升，尤其在 worker 数量多、空闲连接少的场景下属于冗余开销。
如果你真想减少时钟读取频率，应该怎么做
Nginx 本身没有提供“降低时钟采样率”的开关，但可通过以下方式间接减少不必要的时钟访问：
-
保持
timer_resolution未设置（默认行为）：这是绝大多数 HTTP 服务（尤其是短连接、高吞吐型）的最佳选择； -
精简超时相关配置：
- 缩短
keepalive_timeout（例如30s而非300s）→ 减少需定时检查的连接数； - 关闭非必需的超时项，如
resolver_timeout、client_header_timeout（若不用动态 DNS）；
- 缩短
-
避免在
http或server块中误写timer_resolution：该指令只能出现在main块，否则配置会报错或静默忽略； -
确认未被第三方模块强制触发高频时间检查：某些自定义模块可能绕过 Nginx 时间缓存机制，直接调用
clock_gettime()。
什么情况下值得接受更高频率的时钟读取
仅当业务具备以下特征时，才建议启用并合理设置 timer_resolution：
- 大量低流量长连接（如 WebSocket、HTTP/2 流、MQTT 心跳）；
- 对连接空闲超时响应延迟敏感（例如要求 200ms 内断开失效心跳）；
- 可接受约 1%–3% 的额外 CPU 开销作为交换。
此时推荐配置：
-
timer_resolution 100ms;（main 块中）； - 启动后检查 error log 是否出现
using timer resolution字样以确认生效； - 避免低于
50ms，不设为0或1ms。
不复杂但容易忽略。
