ngx_event_timer_resolution控制nginx定时器最小精度，单位毫秒，通过调整epoll_wait超时值影响唤醒频率；设为0时永久阻塞，设为10ms则每10ms强制唤醒检查定时器，过小会显著增加CPU开销和调度压力。

nginx 的 ngx_event_timer_resolution（常被简写为 ngx_event_timer_res）控制事件模块中定时器的最小精度，它不直接“调整内核”，但会显著改变 nginx 与内核 timer 机制的交互方式，进而影响 CPU 占用、延迟响应和系统负载。理解其原理和副作用，比盲目调小更重要。

timer_resolution 是什么？它不等于 setitimer 或 clock_gettime

该配置项（单位为毫秒）告诉 nginx：不必每毫秒都检查一次超时，而是允许将多个定时器“合并”到最近的同一时刻触发，前提是误差不超过设定值。底层依赖的是 epoll/kqueue 的超时参数（epoll_wait 的 timeout 或 kqueue 的 kevent 超时），而非独立的 POSIX timer 或 timerfd。

例如：
- 设为 0（默认）：nginx 每次进入 epoll_wait 都传入 -1（永久阻塞），仅当有 I/O 事件或信号才唤醒；定时器检查只在每次事件循环开始/结束时做一次粗略扫描。
- 设为 10ms：nginx 保证定时器误差 ≤10ms，因此每次调用 epoll_wait 最多等待 10ms，即使无 I/O 也会定期唤醒，以检查到期定时器（如 keepalive 超时、resolver 超时等）。

设小了会怎样？CPU 和内核调度压力明显上升

将 timer_resolution 设为 1ms 或 5ms，看似提升了定时精度，实则带来三重开销：

• 频繁系统调用：每毫秒一次 epoll_wait(timeout=1)，导致上下文切换剧增，尤其在空载或低并发时，CPU 大量时间花在内核态进出上；
• 干扰内核 CFS 调度：短周期唤醒使 nginx worker 进程持续处于 R（运行）或 S（可中断睡眠）状态切换中，降低调度器对长周期任务的友好性，可能挤压其他进程的 CPU 时间片；
• 虚假 wakeups 增加：即使无真实事件，内核仍需按期唤醒进程，触发不必要的事件循环、红黑树遍历和回调执行，浪费 cache line 和分支预测资源。

哪些场景真需要调小？别为“感觉快”而改

绝大多数 HTTP 服务完全不需要 sub-10ms 定时精度。真正受益的场景极少，且必须满足两个条件：高频率、强时效性、用户态主动管理的定时行为 + 内核无法替代。

• 自定义 upstream health check 的亚秒级探测（如每 200ms 发心跳包），且不能依赖 upstream_check_module 等已优化的扩展；
• 实时流代理中极低延迟的 buffer flush 控制（如 WebRTC 转发层需严格控制 jitter buffer 触发时机）；
• 与硬件设备驱动协同的确定性 I/O 调度（如 nginx 作为边缘网关对接 FPGA 加速卡，需精确对齐硬件 timer 中断）。

注意：keepalive timeout、client_header_timeout 等常规超时字段本身不受 timer_resolution 影响——它们由事件循环中定时器红黑树的插入逻辑决定，只要事件循环能定期运行即可，不一定非要靠高频 epoll 唤醒。

更优替代方案：用内核能力代替用户态轮询

若确实需要高精度定时，优先考虑绕过 nginx 自身 timer 机制：

• 用 timerfd_create + epoll_ctl 注册专用定时器 fd：在自定义模块中创建纳秒级精度的单次/周期 timer，由内核精确触发，不干扰主事件循环；
• 启用 SO_BUSY_POLL 或 AF_XDP：减少网络栈延迟，让请求更快到达 nginx，从而降低对“快速响应定时器”的依赖；
• 用 io_uring 替代 epoll（需 patch 或使用 OpenResty 1.25+）：支持带超时的异步等待，内核完成 timer + I/O 复合操作，避免用户态频繁唤醒。

这些方法把精度控制交给内核，既满足需求，又不牺牲整体效率。