Nginx性能依赖Linux内核调优：需设置fs.file-max≥1048576、ulimit -n≥65535；net.core.somaxconn与tcp_max_syn_backlog均设为65535；ip_local_port_range扩至1024-65535；tcp_tw_reuse=1；启用worker_cpu_affinity；vm.swappiness=1；确保SO_REUSEPORT开启且epoll.max_user_watches足够大。
Nginx 多进程模型看似独立运行，实则深度依赖 Linux 内核提供的底层能力。它不直接修改内核，但每个 worker 进程的连接处理、文件读取、网络收发、事件通知等行为，都受制于内核参数配置。调优不到位，再合理的 nginx.conf 也跑不出预期性能，甚至出现 502、连接拒绝、CPU 空转或内存抖动。
文件描述符限制是并发连接的硬门槛
每个 TCP 连接、每个打开的静态文件、每次 upstream 代理请求，都会消耗至少一个文件描述符（fd）。worker_processes × worker_connections 的理论值，必须有内核级支撑才能落地。
- fs.file-max 是系统全局上限，建议设为 1048576（100 万）以上，避免全局耗尽
- ulimit -n 控制单进程软/硬限制，需为 nginx 用户单独配置：soft/hard nofile 均设为 65535 或更高
- 调整后必须在启动 nginx 前生效；若用 systemd 启动，还需检查 LimitNOFILE 是否覆盖了 limits.conf 设置
网络连接队列与端口资源决定建连效率
四层负载均衡或高频反向代理场景下，连接建立速率远高于七层 HTTP，内核 TCP 栈和队列配置直接影响 SYN 接收、TIME_WAIT 复用和本地端口供给。
- net.core.somaxconn 和 net.ipv4.tcp_max_syn_backlog 都要设为 65535，防止全连接队列与半连接队列溢出丢包
- net.ipv4.ip_local_port_range 扩展为 1024 65535，提供约 6.4 万个可用临时端口，支撑大规模 outbound 代理
- net.ipv4.tcp_tw_reuse = 1 必开（配合 tcp_timestamps=1），让 TIME_WAIT socket 可重用于新 outgoing 连接，缓解端口枯竭
CPU 亲和性与调度机制影响缓存命中与上下文切换
worker 进程绑定 CPU 核心不是可选项，而是减少 cache miss 和调度抖动的关键手段——但这需要内核支持且未被运行环境压制。
- 启用 worker_cpu_affinity auto，Nginx 自动按核心数分配掩码，避免手动错配
- 确认内核未禁用 CPU affinity（一般默认开启），同时检查容器或 systemd 单元中是否设置了 TasksMax 或 CPUQuota 导致进程被节流
- vm.swappiness 设为 1，抑制 swap，防止 worker 因内存换出造成延迟尖刺
epoll 与 SO_REUSEPORT 是高并发稳定的底层保障
Nginx 默认使用 epoll，但它高效的前提是内核参数协同。尤其在四层 stream 模块下，“伪惊群”问题本质是内核事件分发机制与多进程竞争的失配。
- 确保监听套接字开启 SO_REUSEPORT（Nginx 1.9.1+ 默认启用，可通过 strace 验证 listen() 调用是否带该 flag）
- epoll.max_user_watches 应足够大（如 524288），避免大量文件监控或长连接导致 epoll 实例满载
- net.core.netdev_max_backlog 提升至 5000，应对网卡中断突发流量，减少软中断丢包
