timer_resolution不能降低系统调用开销，反而轻微增加CPU开销；其真实作用是通过周期性调用clock_gettime提升超时检查灵敏度，尤其利于WebSocket等长连接场景。

timer_resolution 不能降低系统调用开销，反而会轻微增加它。

它的真实作用是提升超时检查的灵敏度

启用 timer_resolution 后，Nginx 会按设定间隔（如 100ms）主动调用 clock_gettime(CLOCK_MONOTONIC) 获取高精度时间戳，从而更及时地发现已超时的连接或请求。这在长连接（如 WebSocket、HTTP/2 空闲流）场景中，能更快释放资源，但不是靠“减少调用”实现的。

• 它不改变 epoll_wait/kqueue 的阻塞行为，也不会合并或跳过事件等待系统调用
• 它只是让 Nginx 在每次事件循环中“更勤快地看时间”，以便更准地计算下次 epoll_wait 应该等多久
• 对短连接、高并发 HTTP 请求场景，基本无感知；对低流量但连接数多的服务，价值更明显

设得太小反而显著增加开销

把 timer_resolution 设为 1ms 或 5ms，会导致每毫秒一次 clock_gettime() 调用：

• 每次调用都是一次用户态到内核态的切换，带来上下文切换成本
• 高频唤醒干扰内核 CFS 调度器，可能挤压其他进程的时间片
• 实测中，空载下 CPU 占用率可能异常升高，主循环响应变慢

真正降低系统调用开销的有效做法

若目标是减少 epoll_wait、accept、read 等系统调用频次或开销，应优先考虑这些方向：

• 启用 reuseport：让多个 worker 直接绑定同一端口，避免 accept 争抢和惊群
• 合理设置 worker_connections 和 multi_accept on：单次 accept 尽量处理多个就绪连接
• 使用 SO_REUSEPORT + EPOLLEXCLUSIVE（Linux 4.5+）：进一步隔离事件分发，减少竞争
• 对静态资源服务，开启 sendfile on 和 tcp_nopush on：减少 read/write 系统调用与数据拷贝

什么时候可以谨慎启用 timer_resolution

仅当满足以下条件时才建议尝试：

• 业务大量依赖长连接（如实时消息、SSE、gRPC 流）
• 观察到 keepalive_timeout 或 resolver timeout 响应延迟明显（比如空闲连接要等 65 秒才断，而非配置的 60 秒）
• 已确认使用 epoll/kqueue，且内核版本 ≥ 4.15
• 设置值控制在 50ms–500ms 区间，避免低于 10ms