在 Nginx 的配置文件中，worker_processes 可能是最不起眼的一個參數(shù)，但它卻是決定服務器性能的基石。

很多初學者的配置里寫著 worker_processes 1; 或者直接抄網上的教程寫 worker_processes 4;。如果你的服務器是 8 核 CPU，設為 1 就是浪費；如果是 1 核云主機，設為 4 就是找死（上下文切換會把 CPU 耗干）。

今天，我們就把這個參數(shù)徹底講透：它到底是什么？怎么設才最科學？在高并發(fā)場景下還有哪些“騷操作”？

一、 核心概念：Nginx 的“多進程”模型

要理解 worker_processes，首先要知道 Nginx 和 Apache 不同，它采用的是主從多進程模型（Master-Worker Model）。

Master Process（主進程）：

• 它是“大腦”，不直接處理用戶請求。
• 負責讀取配置、綁定端口、管理 Worker 進程的啟停。
• 如果 Reload 配置，主進程會啟動新的 Worker，平滑關閉舊的 Worker，不影響服務。

Worker Processes（工作進程）：

• 它們是“肌肉”，真正干活的。
• 每個 Worker 進程都是獨立的，互不干擾，競爭搶奪新連接。
• 關鍵點：Linux 內核會保證，在某一時刻，只有一個 Worker 進程在處理一個連接（避免了鎖競爭）。

公式：

最大并發(fā)連接數(shù) = worker_processes × worker_connections

• worker_processes：進程數(shù)（CPU 核心利用率）
• worker_connections：每個進程允許的最大連接數(shù)（文件句柄限制）

二、 黃金法則：應該設置為多少？

1. 現(xiàn)代標準答案：auto

從 Nginx 1.3.8 和 1.2.5 版本開始，官方提供了一個神選項：

worker_processes auto;

這是目前最推薦的設置。Nginx 會自動檢測服務器的 CPU 核心數(shù)（邏輯核），并設置為相同的數(shù)量。

• 為什么好？ 簡單、準確、自適應。不管你是買的云主機還是物理機，它都能跑滿 CPU 性能且不產生無效切換。

2. 傳統(tǒng)手動設置：等于 CPU 核心數(shù)

如果你使用的是老版本 Nginx，或者想精確控制，原則是：

worker_processes 的值 = CPU 的邏輯核心數(shù)

如何查看核心數(shù)？

• Linux 命令：grep processor /proc/cpuinfo | wc -l
• 或者：lscpu (查看 CPU(s) 那一行)

舉例：

• 你買的是阿里云 2核4G：設置為 2。
• 你本地 i7 處理器（4核8線程）：設置為 8。

3. 特殊情況：什么時候可以“超配”？

既然 CPU 只有 4 核，設為 8 會怎么樣？

• CPU 密集型業(yè)務（如大量 SSL 加密、復雜正則匹配）：絕對不要超過核心數(shù)。設為 8 會導致 CPU 頻繁在不同進程間切換（Context Switch），性能反而下降 30% 以上。
• IO 密集型業(yè)務（如靜態(tài)文件服務器、反向代理）：可以設為核心數(shù)的 1.5 倍甚至 2 倍。
  • 原理：當一個 Worker 在等待磁盤讀寫或網絡響應（阻塞狀態(tài)）時，CPU 是空閑的。此時多出來的 Worker 可以搶占 CPU 處理其他請求。
  • 建議：先設為 auto，壓測時發(fā)現(xiàn) CPU 利用率很低（比如只有 30%）但負載很高，再嘗試增加到 1.5 倍。

三、 進階實戰(zhàn)：綁定 CPU 核心（親和性）

在超高頻并發(fā)（10萬+ QPS）場景下，僅僅設置數(shù)量還不夠。Linux 內核可能會把 Worker 進程在不同 CPU 核心間來回調度，這會導致 CPU Cache（L1/L2/L3）失效，降低命中率。

我們需要用 worker_cpu_affinity 把進程“釘”在特定的核心上。

假設你有 4 個核心，4 個 Worker：

worker_processes 4;
worker_cpu_affinity 0001 0010 0100 1000;

• 0001（二進制）：第 1 個進程綁定到 CPU 0
• 0010（二進制）：第 2 個進程綁定到 CPU 1
• 以此類推…

如果是 8 個核心，4 個 Worker：

worker_cpu_affinity 00000001 00000010 00000100 00001000;

或者讓 Nginx 自動綁定：

worker_cpu_affinity auto;

作用：極大減少 CPU 緩存失效，提升熱點數(shù)據的讀取速度。這是核心交易系統(tǒng)調優(yōu)的必選項。

四、 容易被忽視的“難兄難弟”：worker_connections 與 文件句柄

設置好 worker_processes 后，必須同時檢查 worker_connections，否則進程再多也接不住流量。

events {
    worker_connections 1024;  # 每個worker允許的最大連接數(shù)
}

陷阱：操作系統(tǒng)的文件句柄限制（ulimit）
Nginx 的每個連接都要占用一個文件句柄（File Descriptor）。Linux 默認限制通常是 1024。
如果你設置 worker_connections 1024，4 個進程理論最大連接是 4096，但系統(tǒng)可能在 1024 處就卡住了。

解決方案：修改系統(tǒng)限制

1. 查看當前限制：ulimit -n
2. 修改配置：編輯 /etc/security/limits.conf，加入：

* soft nofile 65535
* hard nofile 65535

• Nginx 內部調優(yōu)：

worker_rlimit_nofile 65535;  # 設置worker進程能打開的最大文件數(shù)

最終并發(fā)能力計算：

4 (進程) × 1024 (連接) = 4096 (最大并發(fā)) —— 這是保守值
實際經過優(yōu)化后，輕松支持 2萬-5萬 并發(fā)連接（Keep-Alive 狀態(tài)下）。

五、 總結與配置模板

不要再盲目填寫數(shù)字了，請根據你的服務器角色選擇配置：

1. 通用/Web應用服務器（推薦配置）

適用于大多數(shù) Django/Java/Go 后端應用，業(yè)務邏輯計算較多。

worker_processes auto;  # 自動匹配CPU核心數(shù)
worker_cpu_affinity auto; # 自動綁定核心（可選，高性能需求開啟）

events {
    worker_connections 2048; # 提升單個進程并發(fā)能力
    use epoll; # Linux下最高效的IO模型
    multi_accept on; # 一次性接受所有新連接
}

2. 靜態(tài)文件/圖片/CDN 服務器

適用于 Nginx 做文件服務器，大量磁盤 IO。

worker_processes auto; 
# 如果IO壓力極大，可嘗試 worker_processes 核心數(shù)*1.5;

events {
    worker_connections 4096;
    use epoll;
}

3. 調試排錯技巧

如果你發(fā)現(xiàn) Nginx 報錯：Too many open files 或者 accept() failed (24: Too many open files)。

1. 檢查 worker_rlimit_nofile 是否夠大（建議 65535+）。
2. 檢查系統(tǒng) ulimit -n 是否夠大。
3. 檢查 worker_connections 是否超過了系統(tǒng)限制。

核心口訣：

1. 無腦首選 auto。
2. CPU 密集型別超核，IO 密集型可加倍。
3. 進程數(shù)配好了，別忘了調大 worker_connections 和系統(tǒng)句柄限制。
4. 追求極致性能？打開 worker_cpu_affinity 綁定核心。

把這幾個參數(shù)吃透，你的 Nginx 就能真正跑滿硬件性能，再也不會出現(xiàn)“CPU 只有 20% 但請求卡死”的詭異現(xiàn)象了。

以上就是Nginx核心參數(shù)worker_processes的設置策略的詳細內容，更多關于Nginx worker_processes設置的資料請關注腳本之家其它相關文章！

最新評論