Nginx高併發下的優化

寫在前面

最近在進行服務器的優化，正好在看nginx相關的知識，因此把一些知識整理一下。參考資料爲《Nginx高性能web服務器詳解》，建議你們都去讀讀這本書。
個人機器爲四核CPU，16G內存。

內核參數優化

把以下的參數追加到Linux系統的/etc/sysctl.conf文件中，而後使用以下命令使修改生效：/sbin/sysctl -p

net.core.netdev_max_backlog = 262144
net.core.somaxconn = 262144
net.ipv4.tcp_max_orphans = 262144
net.ipv4.tcp_max_syn_backlog = 262144
net.ipv4.tcp_timestamps = 0
net.ipv4.tcp_synack_retries = 1
net.ipv4.tcp_syn_retries = 1

net.core.netdev_max_backlog參數

參數net.core.netdev_max_backlog,表示當每一個網絡接口接受數據包的速率比內核處理這些包的速率快時，容許發送隊列的數據包的最大數目，咱們調整爲262144.

net.core.somaxconn

該參數用於調節系統同時發起的TCP鏈接數，通常默認值爲128，在客戶端高併發的請求的狀況下，該默認值較小，可能致使鏈接超時或者重傳問題，咱們能夠根據實際狀況結合併發數來調節此值。

net.ipv4.tcp_max_orphans

該參數用於設定系統中最多容許存在多少TCP套接字不被關聯到任何一個用戶文件句柄上，若是超過這個數字，沒有與用戶文件句柄關聯到TCP套接字將當即被複位，同時發出警告信息，這個限制只是爲了簡單防治Dos攻擊，通常系統內存充足的狀況下，能夠增大這個參數。

net.ipv4.tcp_max_syn_backlog

該參數用於記錄還沒有收到客戶端確認信息的鏈接請求的最大值，對於擁有128內存的系統而言，此參數的默認值爲1024，對小內存的系統則是128，通常在系統內存比較充足的狀況下，能夠增大這個參數的賦值。

net.ipv4.tcp_timestamps

該參數用於設置時間戳，這個能夠避免序列號的卷繞，在一個1Gb/s的鏈路上，遇到之前用過的序列號機率很大，當此值賦值爲0時，警用對於TCP時間戳的支持，默認狀況下，TCP協議會讓內核接受這種異常的數據包，針對Nginx服務器來講，建議將其關閉。

net.ipv4.tcp_synack_retries

該參數用於設置內核放棄TCP鏈接以前向客戶端發送SYN+ACK包的數量，爲了創建對端的鏈接服務，服務器和客戶端須要進行三次握手，第二次握手期間，內核須要發送SYN並附帶一個迴應前一個SYN的ACK，這個參數主要影響這個過程，通常賦予值爲1，即內核放棄鏈接以前發送一次SYN＋ACK包。

net.ipv4.tcp_syn_retries

該參數的做用與上一個參數相似，設置內核放棄創建鏈接以前發送SYN包的數量，賦值爲1。

nginx優化

nginx的配置文件以下：

user www-data;
pid /run/nginx.pid;

worker_processes 4;
worker_cpu_affinity 0001 0010 0100 1000;
worker_rlimit_nofile 65535;


events {
        use epoll;
        worker_connections 65535;
        accept_mutex off;
        multi_accept off;

}

http {

        ##
        # Basic Settings
        ##

        sendfile on;
        tcp_nopush on;
        tcp_nodelay on;
        keepalive_timeout 60 50;
        send_timeout 10s;
        types_hash_max_size 2048;
        client_header_buffer_size 4k;
        client_max_body_size 8m;

        include /etc/nginx/mime.types;
        default_type application/octet-stream;

        ##
        # Logging Settings
        ##

        access_log /var/log/nginx/access.log;
        error_log /var/log/nginx/error.log;

        ##
        # Gzip Settings
        ##

        gzip on;
        gzip_disable "msie6";
        gzip_min_length 1024;
        gzip_vary on;
        gzip_comp_level 2;
        gzip_buffers 32 4k;
        gunzip_static on;
        gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;


        ##
        # Virtual Host Configs
        ##

        include /etc/nginx/conf.d/*.conf;
        include /etc/nginx/sites-enabled/*;
}

worker_processes

worker_processes用來設置Nginx服務的進程數。推薦是CPU內核數或者內核數的倍數，推薦使用CPU內核數，由於個人CPU爲4核的，因此設置爲4。

worker_cpu_affinity

默認狀況下，Nginx的多個進程有可能跑在某一個CPU或CPU的某一核上，致使Nginx進程使用硬件的資源不均，所以綁定Nginx進程到不一樣的CPU上是爲了充分利用硬件的多CPU多核資源的目的。
worker_cpu_affinity用來爲每一個進程分配CPU的工做內核，參數有多個二進制值表示，每一組表明一個進程，每組中的每一位表明該進程使用CPU的狀況，1表明使用，0表明不使用。因此咱們使用worker_cpu_affinity 0001 0010 0100 1000;來讓進程分別綁定不一樣的核上。

worker_connections

設置一個進程理論容許的最大鏈接數，理論上越大越好，但不能夠超過worker_rlimit_nofile的值。還有個問題，linux系統中有個指令open file resource limit，它設置了進程能夠打開的文件句柄數量，能夠用下面的指令查看你的linux系統中open file resource limit指令的值，cat /proc/sys/fs/file-max
能夠將該指令設置爲23900251
echo "2390251" > /proc/sys/fs/file-max; sysctl -p

worker_rlimit_nofile

設置毎個進程的最大文件打開數。若是不設的話上限就是系統的ulimit –n的數字，通常爲65535。

use epoll

設置事件驅動模型使用epoll。事件驅動模型有select、poll、poll等。

• select先建立事件的描述符集合，對於一個描述符，能夠關注其上面的Read事件、Write事件以及Exception事件，因此要建立三類事件描述符集合，分別用來處理Read事件的描述符、Write事件的描述符、Exception事件的描述符，而後調用底層的select()函數，等待事件發生，輪詢全部事件描述符集合的每個事件描述符，檢查是否有事件發生，有的話就處理。select效率低，主要是輪詢效率低，並且還要分別輪詢三個事件描述符的集合。
• poll方法與select相似，都是先建立一個關注事件的描述符集合，再去等待這些事件發生，而後再輪詢描述符集合，檢查有無事件發生，若是有，就去處理。不一樣點是poll爲Read事件、Write事件以及Exception事件只建立一個集合，在每一個描述符對應的結構上分別設置Read事件、Write事件以及Exception事件。最後輪詢的時候，能夠同時檢察權這三個事件是否發生。能夠說，poll庫是select庫的優化實現。
• epoll是Nginx支持的高性能事件驅動庫之一。是公認的很是優秀的事件驅動模型。和poll庫跟select庫有很大的不一樣，最大區別在於效率。咱們知道poll庫跟select庫都是建立一個待處理的事件列表，而後把這個列表發給內核，返回的時候，再去輪詢檢查這個列表，以判斷事件是否發生。這樣在描述符多的應用中，效率就顯得比較低下了。一種比較好的方式是把列表的管理交由內核負責，一旦某種事件發生，內核就把發生事件的描述符列表通知給進程，這樣就避免了輪詢整個描述符列表。首先，epoll庫經過相關調用同志內核建立一個有N個描述符的事件列表，而後給這些描述符設置所關注的事件，並把它添加到內核的事件列表中去。完成設置之後，epoll庫就開始等待內核通知事件發生了，某一事件發生後，內核講發生事件的描述符列表上報給epoll庫，獲得事件列表的epoll庫，就能夠進行事件處理了。epoll庫在linux平臺是高效的，它支持一個進程打開大數目的事件描述符，上限是系統能夠打開文件的最大數目；同時，epoll庫的IO效率不隨描述符數量的增長而線性降低，由於它只會對內核上報的活躍的描述符進行操做。

accept_mutex

這個牽扯到《UNIX網絡編程》第一卷中提到的「驚羣」問題（Thundering herd problem），大體意思是當某一時刻只有一個網絡鏈接到來時，多個睡眠進程會被同時叫醒，但只有一個進程可得到鏈接，若是每次喚醒的進程數目太多，會影響一部分系統性能。在Nginx服務器的多進程下，就可能出現這個問題，爲了解決這個問題，Nginx配置了包含這樣一條指令accept_mutex，當其設置爲開啓的時候，將會對多個Nginx進程接受鏈接進行序列化，防止多個進程對鏈接的爭搶。當服務器鏈接數很少時，開啓這個參數會讓負載有必定程度的下降。可是當服務器的吞吐量很大時，爲了效率，請關閉這個參數；而且關閉這個參數的時候也可讓請求在多個worker間的分配更均衡。因此咱們設置accept_mutex off;

multi_accept

sendfile

使用開啓或關閉是否使用sendfile()傳輸文件，普通應用應該設爲on，下載等IO重負荷的應用應該設爲off，由於大文件不適合放到buffer中。
傳統文件傳輸中（read／write方式）在實現上3實際上是比較複雜的，須要通過屢次上下文切換，當須要對一個文件傳輸時，傳統方式是：

• 調用read函數，文件數據被copy到內核緩衝區
• read函數返回，數據從內核緩衝區copy到用戶緩衝區
• write函數調用，將文件數據從用戶緩衝區copy到內核與socket相關的緩衝區
• 數據從socket緩衝區copy到相關協議引擎

從上面能夠看出來，傳統readwrite進行網絡文件傳輸的方式，在過程當中經歷了四次copy操做。
硬盤－>內核buffer->用戶buffer->socket相關緩衝區->協議引擎
而sendfile系統調用則提供了一種減小屢次copy，提升文件傳輸性能的方法。流程以下：

• sendfile系統效用，文件數據被copy至內核緩衝區
• 記錄數據文職和長度相關的數據保存到socket相關緩存區
• 實際數據由DMA模塊直接發送到協議引擎

tcp_nopush

sendfile爲on時這裏也應該設爲on，數據包會累積一下再一塊兒傳輸，能夠提升一些傳輸效率。

tcp_nodelay

小的數據包不等待直接傳輸。默認爲on。
看上去是和tcp_nopush相反的功能，可是兩邊都爲on時nginx也能夠平衡這兩個功能的使用。

keepalive_timeout

HTTP鏈接的持續時間。設的太長會使無用的線程變的太多。這個根據本身服務器訪問數量、處理速度以及網絡情況方面考慮。

send_timeout

設置Nginx服務器響應客戶端的超時時間，這個超時時間只針對兩個客戶端和服務器創建鏈接後，某次活動之間的時間，若是這個時間後，客戶端沒有任何活動，Nginx服務器將關閉鏈接，將其設置爲10s，Nginx與客戶端創建鏈接後，某次會話中服務器等待客戶端響應超過10s，就會自動關閉。

types_hash_max_size

types_hash_max_size影響散列表的衝突率。types_hash_max_size越大，就會消耗更多的內存，但散列key的衝突率會下降，檢索速度就更快。types_hash_max_size越小，消耗的內存就越小，但散列key的衝突率可能上升。

client_header_buffer_size

該指令用於設置Nginx服務器容許的客戶端請求頭部的緩衝區大小，默認爲1KB，此指令的賦值能夠根據系統分頁大小來設置，分頁大小能夠用如下命令獲取getconf PAGESIZE。

client_max_body_size 8m

客戶端上傳的body的最大值。超過最大值就會發生413(Request Entity Too Large)錯誤。默認爲1m，最好根據本身的狀況改大一點。

gzip on

啓用gzip，對響應數據進行在線實時壓縮,減小數據傳輸量。

gzip_disable

Nginx服務器在響應這些種類的客戶端請求時，不使用Gzip功能緩存應用數據，gzip_disable "msie6"對IE6瀏覽器的數據不進行GZIP壓縮。

gzip_min_length

Gzip壓縮功能對大數據的壓縮效果明顯，可是若是壓縮很小的數據，可能出現越壓縮數據量越大的狀況，所以應該根據相應頁面的大小，選擇性開啓或者關閉Gzip功能。建議將值設置爲1KB。

gzip_comp_level

設置壓縮程度，包括級別1到級別9，級別1表示壓縮程度最低，壓縮效率最高；級別9表示壓縮程度最高，壓縮效率最低，最費時間。

gzip_vary

用於設置在使用Gzip功能時是否發送帶有「Vary：Accept-Encoding」頭域的響應頭部，該頭域的主要功能是告訴接收方發送的數據通過了壓縮處理，開啓後端效果是在響應頭部Accept-Encoding: gzip，對於自己不支持Gzip的壓縮的客戶端瀏覽器是有用的。

gzip_buffers;

該指令用於設置Gzip壓縮文件使用存儲空間的大小，
語法gzip_buffers number size;number，指定Nginx服務器須要向系統申請存儲空間的個數，size，指定每一個緩存空間的大小。根據配置項，Nginx服務器在對響應輸出數據進行Gzip壓縮時需向系統申請numbersize大小的空間用於存儲壓縮數據。默認狀況下，numbersize的值爲128，其中size的值爲系統內存頁一頁的大小，用getconf PAGESIZE來獲取

gunzip_static

開啓時，若是客戶端瀏覽器不支持Gzip處理，Nginx服務器將返回解壓後的數據，若是客戶端瀏覽器支持Gzip處理，Nginx服務器忽略該指令設置。仍然返回壓縮數據。

gzip_types

Nginx服務器能夠根據MIME類型選擇性開啓Gzip壓縮功能。該指令涌來設置MIME類型。