技術標籤：Nginx

CPU親和

CPU親和

CPU親和就是減少程序之間不斷頻繁遷移，減少效能損耗；其實就是worker_cpu_affinity引數的配置，目的將nginx worker繫結到不同核心上，這樣由於worker的爭搶性質，會導致所有的核心都在工作

檢視當前CPU物理狀態

lscpu |grep “CPU(s)”

沒有伺服器，隨便杜撰些真實伺服器的資料吧

CPU(s):                24
On-line CPU(s) list:   0-23
NUMA node0 CPU(s):     0,2,4,6,8,10,12,14,16,18,20,22
NUMA node0 CPU(s):     1,3,5,7,9,11,13,15,17,19,21,23
 

上面的意思是，cpu總共24個核心，有2個物理CPU（看NUMA node0 CPU(s)行數），每一個物理CPU都是12核，0到23是它們的編號

按1

上面有幾核CPU出現就表示幾個核心在工作，0-3，有四個在工作（這個是我真實的虛擬機器的）
如果是上面的24核的真實地伺服器，可能也就%CPU8工作，也就是9個工作，CPU親和的目的就是讓24個核心全部進入工作狀態，也就是lscpu會顯示所有的cpu
如果就只有4核的寫法就比較簡單

#work繫結cpu（4work繫結4cpu）
worker_cpu_affinity 0001 0010 0100 1000;
#######################################################
#work繫結cpu（4work繫結8核cpu中的4個）
#worker_cpu_affinity 00000001 00000010 00000100 00001000
 

按照上面的寫法，24核的CPU的寫法是

worker_processes 24;
worker_cpu_affinity 000000000000000000000001 000000000000000000000010 000000000000000000000100 ... 100000000000000000000000

但是這樣寫太繁雜了
寫法2，其實這種方式也很雞肋

worker_processes 2;
worker_cpu_affinity 010101010101010101010101 101010101010101010101010;

最佳（nginx1.9推出，1.9前都是前面）

worker_processes auto;
worker_cpu_affinity auto;

先別重啟Nginx
檢視nginx worker程序繫結對應的cpu

ps -eo pid,args,psr|grep [n]ginx

一開始是，master繫結3；worker繫結0，1和2沒用上
重啟Nginx，載入配置檔案

可以看到，4個核心都被用上了，而且下表為3的，master和worker都有，如果沒有繫結cpu核心，那worker可能等每次載入進cpu，用的核心都不一樣，每次使用cpu都要判斷哪個核有空之類的檢測，這樣親和就是減少cpu頻繁切換的損耗

再說一下上面的資料，一開始lscpu的時候，我的4核虛擬機器直接全部用上了，因為我沒有伺服器，所以沒法展示，所以杜撰一些伺服器資料來說明，其實一開始，lscpu的話，只會顯示部分cpu，其他核心都是沒工作的，正所謂，一核工作，多核圍觀，額，應該是少核工作，多核圍觀，然後ps程序現象0、3，如果你是伺服器，也是隻有兩個核心被用上，比如可能是12、15，接著設定CPU親和之後，啟動就聲明瞭master和很多worker，每個worker直接繫結cpu的核心，這樣每個核心就不至於圍觀了