Nginx簡單性能調優

Nginx默認沒有開啓利用多核CPU （忍不住吐槽，然怪總感受服務器性能沒充分發揮）, 咱們能夠經過增長worker_cpu_affinity配置參數來充分利用多核CPU。CPU是任務處理，計算最關鍵的資源，CPU核越多，性能就越好。
配置Nginx多核CPU,worker_cpu_affinity使用方法和範例
1、 2核CPU，開啓2個進程
worker_processes 2;
worker_cpu_affinity 01 10;

01表示啓用第一個CPU內核，10表示啓用第二個CPU內核
worker_cpu_affinity 01 10;表示開啓兩個進程，第一個進程對應着第一個CPU內核，第二個進程對應着第二個CPU內核。
2、 2核CPU,開啓4個進程
worker_processes 4;
worker_cpu_affinity 01 10 01 10;

開啓了四個進程，它們分別對應着開啓2個CPU內核
3、 4核CPU，開戶4個進程                
worker_processes 4;
worker_cpu_affinity 0001 0010 0100 1000;

0001表示啓用第一個CPU內核，0010表示啓用第二個CPU內核，依此類推
4、 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表示該內核關閉。
5、 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網卡驅動架構。