nginx 效能優化簡單案例
阿新 • • 發佈：2019-02-07
- Nginx預設沒有開啟利用多核CPU （忍不住吐槽，然怪總感覺伺服器效能沒充分發揮）, 我們可以通過增加worker_cpu_affinity配置引數來充分利用多核CPU。CPU是任務處理，計算最關鍵的資源，CPU核越多，效能就越好。
- 配置Nginx多核CPU,worker_cpu_affinity使用方法和範例
- 一、 2核CPU，開啟2個程序
- worker_processes 2;
- worker_cpu_affinity 01 10;
- 01表示啟用第一個CPU核心，10表示啟用第二個CPU核心
- worker_cpu_affinity 01 10;表示開啟兩個程序，第一個程序對應著第一個CPU核心，第二個程序對應著第二個CPU核心。
- 二、 2核CPU,開啟4個程序
- worker_processes 4;
- worker_cpu_affinity 01 10 01 10;
- 開啟了四個程序，它們分別對應著開啟2個CPU核心
- 三、 4核CPU，開戶4個程序
- worker_processes 4;
- worker_cpu_affinity 0001 0010 0100 1000;
- 0001表示啟用第一個CPU核心，0010表示啟用第二個CPU核心，依此類推
- 四、 4核CPU，開啟2個程序
- worker_processes 2;
- worker_cpu_affinity 0101 1010;
- 0101表示開啟第一個和第三個核心，1010表示開啟第二個和第四個核心
- 2個程序對應著四個核心
- worker_cpu_affinity配置是寫在/etc/nginx/nginx.conf裡面的。
- 2核是 01，四核是0001，8核是00000001，有多少個核，就有幾位數，1表示該核心開啟，0表示該核心關閉。
- 五、 8核CPU，開戶8個程序
- worker_processes 8;
- worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000 10000000;
- 0001表示啟用第一個CPU核心，0010表示啟用第二個CPU核心，依此類推
- worker_processes最多開啟8個，8個以上效能提升不會再提升了，而且穩定性變得更低，所以8個程序夠用了。
- 配置完畢後，重啟nginx ，執行 /etc/init.d/nginx restart
- 測試nginx是否有用到多個CPU核心 ，在另一臺機器上執行 ab.exe -c 1000 -n 1000 http://www.domain.com
- ab.exe是裝apache後帶的一個性能測試工具，它可以模擬多客戶端的併發請求。
- 在伺服器上執行top，然後按1，就可以看到CPU核心的工作情況。如果多個CPU核心的利用率都相差不多，證明nginx己經成功的利用了多核CPU。測試結束後，CPU核心的負載應該都同時降低。
- worker_rlimit_nofile 65535;
- 這個指令是指當一個nginx程序開啟的最多檔案描述符數目，理論值要和系統的單程序開啟檔案數一致，如：linux 2.6核心下開啟檔案開啟數為65535，worker_rlimit_nofile就相應應該填寫65535。
- client_header_buffer_size 4k;
- 客戶端請求頭部的緩衝區大小，這個可以根據你的系統分頁大小來設定，一般一個請求頭的大小不會超過1k，但也有client_header_buffer_size超過4k的情況，注意client_header_buffer_size該值必須設定為"系統分頁大小"的整倍數。
- 分頁大小可以用命令 getconf PAGESIZE 取得。
- events {
- # 語法 use [ kqueue | rtsig | epoll | /dev/poll | select | poll ];
- use epoll; # 使用epoll（linux2.6的高效能方式）
- worker_connections 51200; #每個程序最大連線數（最大連線=連線數×程序數）
- # 併發總數是 worker_processes 和 worker_connections 的乘積
- # 即 max_clients = worker_processes * worker_connections
- # 在設定了反向代理的情況下，max_clients = worker_processes * worker_connections / 4
- # 併發受IO約束，max_clients的值須小於系統可以開啟的最大檔案數
- # 檢視系統可以開啟的最大檔案數
- # cat /proc/sys/fs/file-max
- }
- /* =================== [use epoll 的優點] =================== */
- 1. 支援一個程序開啟大數目的socket描述符(FD)
- select 最不能忍受的是一個程序所開啟的FD是有一定限制的，由FD_SETSIZE設定，預設值是2048。對於那些需要支援的上萬連線數目的IM伺服器來說顯然太少了。這時候你一是可以選擇修改這個巨集然後重新編譯核心，不過資料也同時指出這樣會帶來網路效率的下降，二是可以選擇多程序的解決方案(傳統的 Apache方案)，不過雖然linux上面建立程序的代價比較小，但仍舊是不可忽視的，加上程序間資料同步遠比不上執行緒間同步的高效，所以也不是一種完美的方案。不過 epoll則沒有這個限制，它所支援的FD上限是最大可以開啟檔案的數目，這個數字一般遠大於2048,舉個例子,在1GB記憶體的機器上大約是10萬左右，具體數目可以 cat /proc/sys/fs/file-max 察看,一般來說這個數目和系統記憶體關係很大。
- 2. IO效率不隨FD數目增加而線性下降
- 傳統的select/poll另一個致命弱點就是當你擁有一個很大的socket集合，不過由於網路延時，任一時間只有部分的socket是"活躍"的，但是select/poll每次呼叫都會線性掃描全部的集合，導致效率呈現線性下降。但是epoll不存在這個問題，它只會對"活躍"的socket進行操作---這是因為在核心實現中epoll是根據每個fd上面的callback函式實現的。那麼，只有"活躍"的socket才會主動的去呼叫 callback函式，其他idle狀態socket則不會，在這點上，epoll實現了一個"偽"AIO，因為這時候推動力在os核心。在一些 benchmark中，如果所有的socket基本上都是活躍的---比如一個高速LAN環境，epoll並不比select/poll有什麼效率，相反，如果過多使用epoll_ctl,效率相比還有稍微的下降。但是一旦使用idle connections模擬WAN環境,epoll的效率就遠在select/poll之上了。
- 3. 使用mmap加速核心與使用者空間的訊息傳遞。
- 這點實際上涉及到epoll的具體實現了。無論是select,poll還是epoll都需要核心把FD訊息通知給使用者空間，如何避免不必要的記憶體拷貝就很重要，在這點上，epoll是通過核心於使用者空間mmap同一塊記憶體實現的。而如果你像我一樣從2.5核心就關注epoll的話，一定不會忘記手工 mmap這一步的。
- 4. 核心微調
- 這一點其實不算epoll的優點了，而是整個linux平臺的優點。也許你可以懷疑linux平臺，但是你無法迴避linux平臺賦予你微調核心的能力。比如，核心TCP/IP協議棧使用記憶體池管理sk_buff結構，那麼可以在執行時期動態調整這個記憶體pool(skb_head_pool)的大小。再比如listen函式的第2個引數(TCP完成3次握手的資料包佇列長度)，也可以根據你平臺記憶體大小動態調整。更甚至在一個數據包面數目巨大但同時每個資料包本身大小卻很小的特殊系統上嘗試最新的NAPI網絡卡驅動架構。