不能通过配置 timer_resolution 指令降低 nginx 获取系统时间戳的高频开销——它反而会增加 clock_gettime() 调用频次、上下文切换和 cpu 开销；其设计目标是提升长连接超时判断灵敏度，而非减少时钟读取。
不能通过配置 timer_resolution 指令来降低 Nginx 内部获取系统时间戳的高频开销——它恰恰会增加时钟中断和系统调用频次。
这个指令的设计目标不是“省时间读取”，而是提升超时判断灵敏度：启用后，Nginx 会强制按设定间隔（如 100ms）主动唤醒、调用 clock_gettime(CLOCK_MONOTONIC) 更新内部时间缓存，并检查待超时连接。这带来额外的用户态-内核态切换和 CPU 开销，尤其在短连接、高吞吐场景下属于冗余负担。
为什么 timer_resolution 会增加时钟开销
- 未配置时：Nginx 仅在必要时刻读取一次系统时间（例如 epoll_wait 返回后、收到信号、或处理定时器），且结果被缓存复用，避免重复调用。
-
配置为
timer_resolution 100ms：每 100ms 主动触发一次clock_gettime()，不管是否有事件发生。 -
设为
1ms或0：几乎每个事件循环都执行一次时钟读取，上下文切换明显上升，%sy（系统态 CPU）可测升高。
它本质是用更多系统调用，换更准的空闲连接断连时机——适用于 WebSocket 等长连接服务，不适用于普通 HTTP 服务。
真正减少时钟读取频次的方法
- 保持 timer_resolution 未设置：这是绝大多数业务（尤其是短连接、API 服务、静态资源分发）的默认且最优选择。
-
缩短 keepalive_timeout：例如从
300s改为30s，直接减少需持续监控的空闲连接数量。 -
关闭非必要超时项：
- 若不用动态 DNS，禁用
resolver_timeout； - 若不解析客户端请求头中的复杂字段，可调低或移除
client_header_timeout。
- 若不用动态 DNS，禁用
-
确认指令位置正确：
timer_resolution只能在main块中使用；放在http或server块会被忽略或报错。 -
排查第三方模块干扰：某些自定义模块可能绕过 Nginx 时间缓存机制，自行高频调用
clock_gettime()。
什么情况下才该启用 timer_resolution
仅当同时满足以下条件时，才值得接受其开销：
- 业务承载大量低流量长连接（如 WebSocket、HTTP/2 流、MQTT 心跳）；
- 要求连接空闲超时响应延迟极低（例如必须 ≤200ms 断开失效心跳）；
- 实测发现当前超时行为明显滞后（如
keepalive_timeout 60s，但实际释放要等 68s+）； - 可接受约 1%–3% 的额外 CPU 占用作为交换。
建议值通常为 100ms，避免设为 0 或 ，否则得不偿失。
附：常见误解澄清
-
timer_resolution不影响 Master/Worker 进程间时间同步（它们本就不共享时间）； - 它不控制缓存刷新节奏（缓存清理由 cache manager 异步完成，与定时器无关）；
- 它不降低
epoll_wait调用次数（相反，在信号驱动模式下可能略微增加唤醒频次）； - 它不修改系统级时钟分辨率（如 Windows 的
NtSetTimerResolution），仅作用于单个 worker 进程内部。
不复杂但容易忽略。
