Nginx高并發(fā)下的優(yōu)化

寫在前面

最近在進(jìn)行服務(wù)器的優(yōu)化霉晕，正好在看nginx相關(guān)的知識罐旗，所以把一些知識整理一下柿顶。參考資料為《Nginx高性能web服務(wù)器詳解》祈秕，建議大家都去讀讀這本書渺贤。
我的機器為四核CPU，16G內(nèi)存请毛。

內(nèi)核參數(shù)優(yōu)化

把如下的參數(shù)追加到Linux系統(tǒng)的/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參數(shù)

參數(shù)net.core.netdev_max_backlog,表示當(dāng)每個網(wǎng)絡(luò)接口接受數(shù)據(jù)包的速率比內(nèi)核處理這些包的速率快時，允許發(fā)送隊列的數(shù)據(jù)包的最大數(shù)目方仿，我們調(diào)整為262144.

net.core.somaxconn

該參數(shù)用于調(diào)節(jié)系統(tǒng)同時發(fā)起的TCP連接數(shù)固棚，一般默認(rèn)值為128，在客戶端高并發(fā)的請求的情況下仙蚜，該默認(rèn)值較小此洲，可能導(dǎo)致連接超時或者重傳問題，我們可以根據(jù)實際情況結(jié)合并發(fā)數(shù)來調(diào)節(jié)此值委粉。

net.ipv4.tcp_max_orphans

該參數(shù)用于設(shè)定系統(tǒng)中最多允許存在多少TCP套接字不被關(guān)聯(lián)到任何一個用戶文件句柄上呜师，如果超過這個數(shù)字，沒有與用戶文件句柄關(guān)聯(lián)到TCP套接字將立即被復(fù)位贾节，同時發(fā)出警告信息汁汗，這個限制只是為了簡單防治Dos攻擊，一般系統(tǒng)內(nèi)存充足的情況下栗涂，可以增大這個參數(shù)碰酝。

net.ipv4.tcp_max_syn_backlog

該參數(shù)用于記錄尚未收到客戶端確認(rèn)信息的連接請求的最大值，對于擁有128內(nèi)存的系統(tǒng)而言戴差，此參數(shù)的默認(rèn)值為1024，對小內(nèi)存的系統(tǒng)則是128铛嘱，一般在系統(tǒng)內(nèi)存比較充足的情況下暖释，可以增大這個參數(shù)的賦值。

net.ipv4.tcp_timestamps

該參數(shù)用于設(shè)置時間戳墨吓，這個可以避免序列號的卷繞球匕，在一個1Gb/s的鏈路上，遇到以前用過的序列號概率很大帖烘，當(dāng)此值賦值為0時亮曹，警用對于TCP時間戳的支持，默認(rèn)情況下，TCP協(xié)議會讓內(nèi)核接受這種異常的數(shù)據(jù)包照卦，針對Nginx服務(wù)器來說式矫，建議將其關(guān)閉。

net.ipv4.tcp_synack_retries

該參數(shù)用于設(shè)置內(nèi)核放棄TCP連接之前向客戶端發(fā)送SYN+ACK包的數(shù)量役耕，為了建立對端的連接服務(wù)采转，服務(wù)器和客戶端需要進(jìn)行三次握手，第二次握手期間瞬痘，內(nèi)核需要發(fā)送SYN并附帶一個回應(yīng)前一個SYN的ACK故慈，這個參數(shù)主要影響這個過程，一般賦予值為1框全，即內(nèi)核放棄連接之前發(fā)送一次SYN＋ACK包察绷。

net.ipv4.tcp_syn_retries

該參數(shù)的作用與上一個參數(shù)類似，設(shè)置內(nèi)核放棄建立連接之前發(fā)送SYN包的數(shù)量津辩，賦值為1拆撼。

nginx優(yōu)化

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用來設(shè)置Nginx服務(wù)的進(jìn)程數(shù)。推薦是CPU內(nèi)核數(shù)或者內(nèi)核數(shù)的倍數(shù)丹泉，推薦使用CPU內(nèi)核數(shù)情萤，因為我的CPU為4核的，所以設(shè)置為4摹恨。

worker_cpu_affinity

默認(rèn)情況下筋岛，Nginx的多個進(jìn)程有可能跑在某一個CPU或CPU的某一核上，導(dǎo)致Nginx進(jìn)程使用硬件的資源不均晒哄，因此綁定Nginx進(jìn)程到不同的CPU上是為了充分利用硬件的多CPU多核資源的目的睁宰。

worker_cpu_affinity用來為每個進(jìn)程分配CPU的工作內(nèi)核，參數(shù)有多個二進(jìn)制值表示寝凌，每一組代表一個進(jìn)程柒傻，每組中的每一位代表該進(jìn)程使用CPU的情況，1代表使用较木，0代表不使用红符。所以我們使用worker_cpu_affinity 0001 0010 0100 1000;來讓進(jìn)程分別綁定不同的核上。

worker_connections

設(shè)置一個進(jìn)程理論允許的最大連接數(shù)伐债，理論上越大越好预侯，但不可以超過worker_rlimit_nofile的值。還有個問題峰锁，linux系統(tǒng)中有個指令open file resource limit萎馅，它設(shè)置了進(jìn)程可以打開的文件句柄數(shù)量，可以用下面的指令查看你的linux系統(tǒng)中open file resource limit指令的值虹蒋，cat /proc/sys/fs/file-max
可以將該指令設(shè)置為23900251

echo "2390251" > /proc/sys/fs/file-max; sysctl -p
worker_rlimit_nofile

設(shè)置毎個進(jìn)程的最大文件打開數(shù)糜芳。如果不設(shè)的話上限就是系統(tǒng)的ulimit –n的數(shù)字飒货，一般為65535。

use epoll

設(shè)置事件驅(qū)動模型使用epoll峭竣。事件驅(qū)動模型有select塘辅、poll、poll等邪驮。

  • select先創(chuàng)建事件的描述符集合莫辨，對于一個描述符，可以關(guān)注其上面的Read事件毅访、Write事件以及Exception事件沮榜，所以要創(chuàng)建三類事件描述符集合，分別用來處理Read事件的描述符喻粹、Write事件的描述符蟆融、Exception事件的描述符，然后調(diào)用底層的select()函數(shù)守呜，等待事件發(fā)生型酥，輪詢所有事件描述符集合的每一個事件描述符，檢查是否有事件發(fā)生查乒，有的話就處理弥喉。select效率低，主要是輪詢效率低玛迄，而且還要分別輪詢?nèi)齻€事件描述符的集合由境。

  • poll方法與select類似，都是先創(chuàng)建一個關(guān)注事件的描述符集合蓖议，再去等待這些事件發(fā)生虏杰，然后再輪詢描述符集合，檢查有無事件發(fā)生勒虾，如果有纺阔，就去處理。不同點是poll為Read事件修然、Write事件以及Exception事件只創(chuàng)建一個集合笛钝，在每個描述符對應(yīng)的結(jié)構(gòu)上分別設(shè)置Read事件、Write事件以及Exception事件愕宋。最后輪詢的時候婆翔，可以同時檢察權(quán)這三個事件是否發(fā)生√蜕簦可以說，poll庫是select庫的優(yōu)化實現(xiàn)潭陪。

  • epoll是Nginx支持的高性能事件驅(qū)動庫之一雄妥。是公認(rèn)的非常優(yōu)秀的事件驅(qū)動模型最蕾。和poll庫跟select庫有很大的不同，最大區(qū)別在于效率老厌。我們知道poll庫跟select庫都是創(chuàng)建一個待處理的事件列表瘟则，然后把這個列表發(fā)給內(nèi)核，返回的時候枝秤，再去輪詢檢查這個列表醋拧，以判斷事件是否發(fā)生。這樣在描述符多的應(yīng)用中淀弹，效率就顯得比較低下了丹壕。一種比較好的方式是把列表的管理交由內(nèi)核負(fù)責(zé)，一旦某種事件發(fā)生薇溃，內(nèi)核就把發(fā)生事件的描述符列表通知給進(jìn)程菌赖，這樣就避免了輪詢整個描述符列表。首先沐序，epoll庫通過相關(guān)調(diào)用同志內(nèi)核創(chuàng)建一個有N個描述符的事件列表琉用，然后給這些描述符設(shè)置所關(guān)注的事件，并把它添加到內(nèi)核的事件列表中去策幼。完成設(shè)置以后邑时，epoll庫就開始等待內(nèi)核通知事件發(fā)生了，某一事件發(fā)生后特姐，內(nèi)核講發(fā)生事件的描述符列表上報給epoll庫晶丘，得到事件列表的epoll庫，就可以進(jìn)行事件處理了到逊。epoll庫在linux平臺是高效的铣口，它支持一個進(jìn)程打開大數(shù)目的事件描述符，上限是系統(tǒng)可以打開文件的最大數(shù)目觉壶；同時脑题，epoll庫的IO效率不隨描述符數(shù)量的增加而線性下降，因為它只會對內(nèi)核上報的活躍的描述符進(jìn)行操作铜靶。

accept_mutex

這個牽扯到《UNIX網(wǎng)絡(luò)編程》第一卷中提到的“驚群”問題（Thundering herd problem）叔遂，大致意思是當(dāng)某一時刻只有一個網(wǎng)絡(luò)連接到來時，多個睡眠進(jìn)程會被同時叫醒争剿，但只有一個進(jìn)程可獲得連接已艰，如果每次喚醒的進(jìn)程數(shù)目太多，會影響一部分系統(tǒng)性能蚕苇。在Nginx服務(wù)器的多進(jìn)程下哩掺，就可能出現(xiàn)這個問題，為了解決這個問題涩笤，Nginx配置了包含這樣一條指令accept_mutex嚼吞，當(dāng)其設(shè)置為開啟的時候盒件，將會對多個Nginx進(jìn)程接受連接進(jìn)行序列化，防止多個進(jìn)程對連接的爭搶舱禽。當(dāng)服務(wù)器連接數(shù)不多時炒刁，開啟這個參數(shù)會讓負(fù)載有一定程度的降低。但是當(dāng)服務(wù)器的吞吐量很大時誊稚，為了效率翔始，請關(guān)閉這個參數(shù)；并且關(guān)閉這個參數(shù)的時候也可以讓請求在多個worker間的分配更均衡里伯。所以我們設(shè)置accept_mutex off;

multi_accept

sendfile

使用開啟或關(guān)閉是否使用sendfile()傳輸文件城瞎，普通應(yīng)用應(yīng)該設(shè)為on，下載等IO重負(fù)荷的應(yīng)用應(yīng)該設(shè)為off俏脊，因為大文件不適合放到buffer中全谤。
傳統(tǒng)文件傳輸中（read／write方式）在實現(xiàn)上3其實是比較復(fù)雜的，需要經(jīng)過多次上下文切換爷贫，當(dāng)需要對一個文件傳輸時认然，傳統(tǒng)方式是：

  • 調(diào)用read函數(shù)，文件數(shù)據(jù)被copy到內(nèi)核緩沖區(qū)
  • read函數(shù)返回漫萄，數(shù)據(jù)從內(nèi)核緩沖區(qū)copy到用戶緩沖區(qū)
  • write函數(shù)調(diào)用卷员，將文件數(shù)據(jù)從用戶緩沖區(qū)copy到內(nèi)核與socket相關(guān)的緩沖區(qū)
  • 數(shù)據(jù)從socket緩沖區(qū)copy到相關(guān)協(xié)議引擎

從上面可以看出來，傳統(tǒng)readwrite進(jìn)行網(wǎng)絡(luò)文件傳輸?shù)姆绞教谖瘢谶^程中經(jīng)歷了四次copy操作毕骡。
硬盤－>內(nèi)核buffer->用戶buffer->socket相關(guān)緩沖區(qū)->協(xié)議引擎
而sendfile系統(tǒng)調(diào)用則提供了一種減少多次copy，提高文件傳輸性能的方法岩瘦。流程如下：

  • sendfile系統(tǒng)效用未巫，文件數(shù)據(jù)被copy至內(nèi)核緩沖區(qū)
  • 記錄數(shù)據(jù)文職和長度相關(guān)的數(shù)據(jù)保存到socket相關(guān)緩存區(qū)
  • 實際數(shù)據(jù)由DMA模塊直接發(fā)送到協(xié)議引擎
tcp_nopush

sendfile為on時這里也應(yīng)該設(shè)為on，數(shù)據(jù)包會累積一下再一起傳輸启昧，可以提高一些傳輸效率叙凡。

tcp_nodelay

小的數(shù)據(jù)包不等待直接傳輸。默認(rèn)為on密末。
看上去是和tcp_nopush相反的功能握爷，但是兩邊都為on時nginx也可以平衡這兩個功能的使用。

keepalive_timeout

HTTP連接的持續(xù)時間严里。設(shè)的太長會使無用的線程變的太多新啼。這個根據(jù)自己服務(wù)器訪問數(shù)量、處理速度以及網(wǎng)絡(luò)狀況方面考慮刹碾。

send_timeout

設(shè)置Nginx服務(wù)器響應(yīng)客戶端的超時時間燥撞，這個超時時間只針對兩個客戶端和服務(wù)器建立連接后，某次活動之間的時間，如果這個時間后叨吮，客戶端沒有任何活動辆布，Nginx服務(wù)器將關(guān)閉連接，將其設(shè)置為10s茶鉴，Nginx與客戶端建立連接后，某次會話中服務(wù)器等待客戶端響應(yīng)超過10s景用，就會自動關(guān)閉涵叮。

types_hash_max_size

types_hash_max_size影響散列表的沖突率。types_hash_max_size越大伞插，就會消耗更多的內(nèi)存割粮，但散列key的沖突率會降低，檢索速度就更快媚污。types_hash_max_size越小舀瓢，消耗的內(nèi)存就越小，但散列key的沖突率可能上升耗美。

client_header_buffer_size

該指令用于設(shè)置Nginx服務(wù)器允許的客戶端請求頭部的緩沖區(qū)大小京髓，默認(rèn)為1KB，此指令的賦值可以根據(jù)系統(tǒng)分頁大小來設(shè)置商架，分頁大小可以用以下命令獲取getconf PAGESIZE堰怨。

client_max_body_size 8m

客戶端上傳的body的最大值。超過最大值就會發(fā)生413(Request Entity Too Large)錯誤蛇摸。默認(rèn)為1m备图，最好根據(jù)自己的情況改大一點。

gzip on

啟用gzip赶袄，對響應(yīng)數(shù)據(jù)進(jìn)行在線實時壓縮,減少數(shù)據(jù)傳輸量揽涮。

gzip_disable

Nginx服務(wù)器在響應(yīng)這些種類的客戶端請求時，不使用Gzip功能緩存應(yīng)用數(shù)據(jù)饿肺，gzip_disable "msie6"對IE6瀏覽器的數(shù)據(jù)不進(jìn)行GZIP壓縮蒋困。

gzip_min_length

Gzip壓縮功能對大數(shù)據(jù)的壓縮效果明顯，但是如果壓縮很小的數(shù)據(jù)唬格，可能出現(xiàn)越壓縮數(shù)據(jù)量越大的情況家破，因此應(yīng)該根據(jù)相應(yīng)頁面的大小，選擇性開啟或者關(guān)閉Gzip功能购岗。建議將值設(shè)置為1KB汰聋。

gzip_comp_level

設(shè)置壓縮程度，包括級別1到級別9喊积，級別1表示壓縮程度最低烹困，壓縮效率最高；級別9表示壓縮程度最高乾吻，壓縮效率最低髓梅，最費時間拟蜻。

gzip_vary

用于設(shè)置在使用Gzip功能時是否發(fā)送帶有“Vary：Accept-Encoding”頭域的響應(yīng)頭部，該頭域的主要功能是告訴接收方發(fā)送的數(shù)據(jù)經(jīng)過了壓縮處理枯饿，開啟后端效果是在響應(yīng)頭部Accept-Encoding: gzip酝锅，對于本身不支持Gzip的壓縮的客戶端瀏覽器是有用的。

gzip_buffers;

該指令用于設(shè)置Gzip壓縮文件使用存儲空間的大小奢方，
語法gzip_buffers number size;number搔扁，指定Nginx服務(wù)器需要向系統(tǒng)申請存儲空間的個數(shù)，size蟋字，指定每個緩存空間的大小稿蹲。根據(jù)配置項，Nginx服務(wù)器在對響應(yīng)輸出數(shù)據(jù)進(jìn)行Gzip壓縮時需向系統(tǒng)申請numbersize大小的空間用于存儲壓縮數(shù)據(jù)鹊奖。默認(rèn)情況下苛聘，numbersize的值為128，其中size的值為系統(tǒng)內(nèi)存頁一頁的大小忠聚，用getconf PAGESIZE來獲取

gunzip_static

開啟時设哗，如果客戶端瀏覽器不支持Gzip處理，Nginx服務(wù)器將返回解壓后的數(shù)據(jù)咒林，如果客戶端瀏覽器支持Gzip處理熬拒，Nginx服務(wù)器忽略該指令設(shè)置。仍然返回壓縮數(shù)據(jù)垫竞。

gzip_types

Nginx服務(wù)器可以根據(jù)MIME類型選擇性開啟Gzip壓縮功能澎粟。該指令涌來設(shè)置MIME類型。

轉(zhuǎn)載https://segmentfault.com/a/1190000011405320

最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 人面猴
    序言：七十年代末欢瞪，一起剝皮案震驚了整個濱河市活烙，隨后出現(xiàn)的幾起案子，更是在濱河造成了極大的恐慌遣鼓，老刑警劉巖啸盏，帶你破解...
    沈念sama閱讀 217,509評論 6贊 504
  • 死咒
    序言：濱河連續(xù)發(fā)生了三起死亡事件，死亡現(xiàn)場離奇詭異骑祟，居然都是意外死亡回懦，警方通過查閱死者的電腦和手機，發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 92,806評論 3贊 394
  • 救了他兩次的神仙讓他今天三更去死
    文/潘曉璐 我一進(jìn)店門次企，熙熙樓的掌柜王于貴愁眉苦臉地迎上來怯晕，“玉大人，你說我怎么就攤上這事缸棵≈鄄瑁” “怎么了？”我有些...
    開封第一講書人閱讀 163,875評論 0贊 354
  • 道士緝兇錄：失蹤的賣姜人
    文/不壞的土叔 我叫張陵，是天一觀的道長吧凉。 經(jīng)常有香客問我隧出，道長，這世上最難降的妖魔是什么阀捅？ 我笑而不...
    開封第一講書人閱讀 58,441評論 1贊 293
  • ?港島之戀（遺憾婚禮）
    正文 為了忘掉前任胀瞪，我火速辦了婚禮，結(jié)果婚禮上饲鄙，老公的妹妹穿的比我還像新娘赏廓。我一直安慰自己，他們只是感情好傍妒，可當(dāng)我...
    茶點故事閱讀 67,488評論 6贊 392
  • 惡毒庶女頂嫁案：這布局不是一般人想出來的
    文/花漫 我一把揭開白布。 她就那樣靜靜地躺著摸柄，像睡著了一般颤练。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上驱负，一...
    開封第一講書人閱讀 51,365評論 1贊 302
  • 城市分裂傳說
    那天嗦玖，我揣著相機與錄音，去河邊找鬼跃脊。 笑死宇挫，一個胖子當(dāng)著我的面吹牛，可吹牛的內(nèi)容都是我干的酪术。 我是一名探鬼主播器瘪，決...
    沈念sama閱讀 40,190評論 3贊 418
  • 雙鴛鴦連環(huán)套：你想象不到人心有多黑
    文/蒼蘭香墨 我猛地睜開眼，長吁一口氣：“原來是場噩夢啊……” “哼绘雁！你這毒婦竟也來了橡疼？” 一聲冷哼從身側(cè)響起，我...
    開封第一講書人閱讀 39,062評論 0贊 276
  • 萬榮殺人案實錄
    序言：老撾萬榮一對情侶失蹤庐舟，失蹤者是張志新（化名）和其女友劉穎欣除，沒想到半個月后，有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體挪略，經(jīng)...
    沈念sama閱讀 45,500評論 1贊 314
  • ?護(hù)林員之死
    正文 獨居荒郊野嶺守林人離奇死亡历帚，尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 37,706評論 3贊 335
  • ?白月光啟示錄
    正文 我和宋清朗相戀三年，在試婚紗的時候發(fā)現(xiàn)自己被綠了杠娱。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片挽牢。...
    茶點故事閱讀 39,834評論 1贊 347
  • 活死人
    序言：一個原本活蹦亂跳的男人離奇死亡，死狀恐怖墨辛，靈堂內(nèi)的尸體忽然破棺而出卓研，到底是詐尸還是另有隱情，我是刑警寧澤，帶...
    沈念sama閱讀 35,559評論 5贊 345
  • ?日本核電站爆炸內(nèi)幕
    正文 年R本政府宣布奏赘，位于F島的核電站寥闪，受9級特大地震影響，放射性物質(zhì)發(fā)生泄漏磨淌。R本人自食惡果不足惜疲憋，卻給世界環(huán)境...
    茶點故事閱讀 41,167評論 3贊 328
  • 男人毒藥：我在死后第九天來索命
    文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望梁只。 院中可真熱鬧缚柳，春花似錦、人聲如沸搪锣。這莊子的主人今日做“春日...
    開封第一講書人閱讀 31,779評論 0贊 22
  • 一樁弒父案，背后竟有這般陰謀
    文/蒼蘭香墨 我抬頭看了看天上的太陽构舟。三九已至灰追，卻和暖如春，著一層夾襖步出監(jiān)牢的瞬間狗超，已是汗流浹背弹澎。 一陣腳步聲響...
    開封第一講書人閱讀 32,912評論 1贊 269
  • 情欲美人皮
    我被黑心中介騙來泰國打工芽隆， 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留柒昏，地道東北人。 一個月前我還...
    沈念sama閱讀 47,958評論 2贊 370
  • 代替公主和親
    正文 我出身青樓委造，卻偏偏與公主長得像渗稍，于是被迫代替她去往敵國和親佩迟。 傳聞我的和親對象是個殘疾皇子，可洞房花燭夜當(dāng)晚...
    茶點故事閱讀 44,779評論 2贊 354