timer_resolution不能降低系统时间请求频率，反而会显著增加clock_gettime()调用次数、上下文切换和CPU开销；它仅用于提升长连接超时检查灵敏度，属以资源换精度的权衡机制。
timer_resolution 指令不能降低 Nginx 内部获取系统时间戳的频率，更不减少安全路径调度开销——恰恰相反，它会显著增加 clock_gettime() 系统调用次数、上下文切换和 CPU 开销。所谓“高频安全路径调度开销”并非真实存在的技术概念，当前主流内核与 Nginx 架构中，时间戳读取本身不触发安全路径调度（如 SELinux AVC 检查、AppArmor 策略匹配等）；它只是轻量级的 clock_gettime(CLOCK_MONOTONIC) 系统调用，不涉及权限校验或策略决策。
如果你观察到高系统态 CPU（%sy）、频繁上下文切换或调度延迟，根源通常不在时间读取本身，而在于：
- 启用了过小的
timer_resolution（如1ms或0），导致每毫秒强制唤醒 worker 进程并调用clock_gettime() - 存在大量空闲长连接，但
keepalive_timeout设置过高（如 300s），使超时检查负担加重 - 使用了低效事件模型（如
select/poll而非epoll），放大超时计算开销 - 第三方模块绕过 Nginx 时间缓存机制，自行高频调用时钟接口
正确理解 timer_resolution 的作用范围
- 仅作用于单个 worker 进程内部，控制其主动刷新本地时间缓存的间隔
- 不影响 master 进程，不涉及进程间同步，也不改变系统时钟精度或安全策略行为
- 不是性能优化开关，而是灵敏度权衡开关：换更准的超时判断，代价是更高频的内核调用
如何真正降低时间相关开销
保持 timer_resolution 未配置（推荐默认）
Nginx 在事件驱动循环中按需读取时间（如 epoll_wait 返回后、收到信号时），并缓存复用，避免冗余调用-
缩短并精简超时配置
-
keepalive_timeout 30s;（而非 300s）→ 减少待检连接数 - 关闭非必要超时：
resolver_timeout 5s;、client_header_timeout 20s;（若无动态 DNS 或慢客户端） - 避免在
http或server块误写该指令（仅允许出现在main块，否则静默忽略或报错）
-
-
确认使用高效事件模型
use epoll; # Linux 下必须显式启用，避免回退到 select/poll
排查第三方模块干扰
某些监控 SDK、自定义限流模块或 WebSocket 扩展可能内置高频定时器，应审查其文档，关闭心跳轮询或拉大间隔
什么情况下才考虑启用 timer_resolution
仅当满足全部以下条件：
- 业务承载大量低流量长连接（如 WebSocket、HTTP/2 流、MQTT）
- 实测空闲连接断开延迟明显超过
keepalive_timeout（例如设为 60s，实际等待 72s 才释放） - 可接受约 1%–3% 的额外 CPU 占用（尤其在 worker 数 > CPU 核心数时更敏感）
- 配置值不低于 10ms（如
timer_resolution 100ms;），且置于main块顶层
⚠️ 注意：设为
0或1ms会导致几乎每个事件循环都触发clock_gettime()，在高并发短连接场景下属于典型负优化。
不复杂但容易忽略——默认不配，就是最优解。
