timer_resolution不能降低系统调用开销，仅提升长连接超时判断及时性；真正优化需启用reuseport、合理设置worker_connections、精简超时参数并确认使用epoll。
timer_resolution 不能降低系统调用开销，反而会轻微增加开销。它不减少 epoll_wait、kqueue 等事件等待系统调用的次数，也不优化 worker 进程在高并发下的调度负担。
timer_resolution 的真实作用
该指令仅影响 Nginx 主进程或 worker 进程读取高精度时钟（如 clock_gettime）的频率，目的是让超时判断更及时，尤其在大量空闲长连接（如 WebSocket、HTTP/2 流、Keep-Alive 连接）场景下，能更快释放过期连接。它：
- 不改变 epoll/kqueue 的阻塞逻辑，timeout 参数仍由 Nginx 内部计算后传入
- 不提升内核定时器精度，也不修改系统时钟分辨率
- 启用后会周期性触发 clock_gettime() 调用，属于额外的用户态-内核态切换
- 对短连接、高吞吐 HTTP 服务基本无收益，甚至因频繁读时钟带来冗余负载
真正降低高并发下系统调用开销的方法
若目标是减少 worker 进程的系统调用（尤其是 epoll_wait/kqueue 等事件等待），应优先采用以下配置与机制：
-
启用 reuseport：在 listen 指令中添加
reuseport，使内核将新连接均匀分发到多个 worker，避免 accept 竞争和惊群效应，显著降低单个 worker 的事件处理压力 - 合理设置 worker_connections：匹配系统 ulimit -n 和实际连接规模，避免连接数溢出导致反复 retry 或 fallback 到低效模式
- 关闭不必要的定时检查：如非必需，禁用 resolver timeout、client_header_timeout 等长周期超时；精简 keepalive_timeout 值（例如设为 30s 而非 300s），减少待检连接数
- 确认使用高效事件模型：Linux 下确保使用 epoll（默认），而非 select/poll；可通过 error log 中 “using epoll” 验证
关于 timer_resolution 的正确用法
仅当业务存在大量低流量长连接，且对连接空闲超时响应延迟敏感（如实时信令、IoT 心跳）时，才考虑启用：
- 只能放在 main 块，语法如：
timer_resolution 100ms; - 推荐值范围为 50ms–500ms；避免设为 1ms 或 0（后者等效于每次事件循环都读时钟）
- 启动后查看 error log，出现
using timer resolution表示生效 - 设为 0 并不会“提升性能”，只会让时间缓存更新最频繁，CPU 开销略升
如果当前瓶颈是系统调用过多，重点应放在连接分发、事件模型和超时策略上，而不是调整 timer_resolution。
