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

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

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

一、 核心概念：Nginx 的“多進(jìn)程”模型

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

Master Process（主進(jìn)程）：

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

Worker Processes（工作進(jìn)程）：

• 它們是“肌肉”，真正干活的。
• 每個(gè) Worker 進(jìn)程都是獨(dú)立的，互不干擾，競爭搶奪新連接。
• 關(guān)鍵點(diǎn)：Linux 內(nèi)核會保證，在某一時(shí)刻，只有一個(gè) Worker 進(jìn)程在處理一個(gè)連接（避免了鎖競爭）。

公式：

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

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

二、 黃金法則：應(yīng)該設(shè)置為多少？

1. 現(xiàn)代標(biāo)準(zhǔn)答案：auto

從 Nginx 1.3.8 和 1.2.5 版本開始，官方提供了一個(gè)神選項(xiàng)：

worker_processes auto;

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

• 為什么好？ 簡單、準(zhǔn)確、自適應(yīng)。不管你是買的云主機(jī)還是物理機(jī)，它都能跑滿 CPU 性能且不產(chǎn)生無效切換。

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

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

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

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

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

舉例：

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

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

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

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

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

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

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

假設(shè)你有 4 個(gè)核心，4 個(gè) Worker：

worker_processes 4;
worker_cpu_affinity 0001 0010 0100 1000;

• 0001（二進(jìn)制）：第 1 個(gè)進(jìn)程綁定到 CPU 0
• 0010（二進(jìn)制）：第 2 個(gè)進(jìn)程綁定到 CPU 1
• 以此類推…

如果是 8 個(gè)核心，4 個(gè) Worker：

worker_cpu_affinity 00000001 00000010 00000100 00001000;

或者讓 Nginx 自動綁定：

worker_cpu_affinity auto;

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

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

設(shè)置好 worker_processes 后，必須同時(shí)檢查 worker_connections，否則進(jìn)程再多也接不住流量。

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

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

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

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

* soft nofile 65535
* hard nofile 65535

• Nginx 內(nèi)部調(diào)優(yōu)：

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

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

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

五、 總結(jié)與配置模板

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

1. 通用/Web應(yīng)用服務(wù)器（推薦配置）

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

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

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

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

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

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

events {
    worker_connections 4096;
    use epoll;
}

3. 調(diào)試排錯技巧

如果你發(fā)現(xiàn) Nginx 報(bào)錯：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. 進(jìn)程數(shù)配好了，別忘了調(diào)大 worker_connections 和系統(tǒng)句柄限制。
4. 追求極致性能？打開 worker_cpu_affinity 綁定核心。

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

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