Nginx多进程架构需动态调优：worker_processes auto智能适配CPU架构；CPU亲和性应随硬件老化/扩容调整；资源限制（如worker_rlimit_nofile）须匹配物理能力；x86与ARM需差异化调优并显式指定Docker平台。
Nginx 多进程架构不是配一次就一劳永逸的静态配置，而是需要随服务器硬件性能变化持续校准的动态系统。核心在于让 worker 进程数量、CPU 绑定策略和资源分配，始终与当前物理资源能力对齐。
根据实际 CPU 架构自动适配进程数
worker_processes auto 是最基础也最关键的动态适配手段。它不是简单读取逻辑核数，而是结合 CPU 类型（x86/ARM）、超线程状态、NUMA 节点分布，智能选择最优进程数：
- 在 x86 服务器上，auto 会避开超线程对，优先匹配物理核心数
- 在 ARM64 多核平台（如鲲鹏 64 核），auto 能识别全部可用逻辑核，并配合内核调度特性合理分配
- 容器环境中，auto 依赖 cgroup 暴露的 vCPU 数；若未限制，则可能误判，此时应显式设为容器实际分配的核心数
按硬件老化与扩容节奏调整 CPU 亲和性
CPU 绑定不是上线时写死就完事，而要响应硬件生命周期变化：
- 新机器上线初期，先用 worker_cpu_affinity auto 启动，观察 24 小时内各核负载是否均衡；若发现某核持续高于 90%，说明绑定未生效或存在 NUMA 不均衡
- 老旧服务器出现频繁 GC 或 TLS 握手延迟上升时，可临时将对应 worker 的 affinity 掩码停用（注释掉该行），让调度器接管，避免强绑定放大性能衰减
- 批量增加物理节点时，不直接修改全局 affinity 掩码，而是逐台新增 server 块并启用独立 worker_cpu_affinity，确保流量渐进迁移
资源上限同步硬件能力演进
worker 进程数提升后，配套资源必须跟上，否则多进程反而成瓶颈：
- worker_rlimit_nofile 需随物理内存增长同步调高：32GB 内存建议设为 65535，128GB 可设为 131072
- 系统级 fs.file-max 应 ≥ nginx 所有 worker 的文件描述符总和（即 worker_processes × worker_rlimit_nofile）
- ARM 服务器 IO 调度器（如 mq-deadline）和 x86 的 deadline 行为不同，需分别验证 aio/directio 是否开启有效，避免因底层差异导致 sendfile 效率下降
跨架构统一运维但差异化调优
同一套 Nginx 配置在 x86 和 ARM 上不能照搬：
- x86 环境下更依赖 sendfile + tcp_nopush 实现零拷贝，ARM64 则可叠加 aio on 提升大文件吞吐
- ssl_buffer_size 在支持 ARMv8 Crypto Extensions 的芯片上可设为 4k，在 x86 上若无 QAT 加速卡，保持默认 1k 更稳
- Docker 部署时，必须用 --platform 显式指定目标架构，否则镜像内嵌的二进制可能调用不兼容指令集，引发 SIGILL
不复杂但容易忽略
