在日常的運維工作中，經常會用到nginx服務，也時常會碰到nginx因高并發導緻的性能瓶頸問題。這裡簡單梳理下nginx性能優化的配置
一、Nginx配置中比較重要的優化項如下：
1）nginx程序數，建議按照cpu數目來指定，一般跟cpu核數相同或為它的倍數。
worker_processes 8;
2）為每個程序配置設定cpu，上例中将8個程序配置設定到8個cpu，當然可以寫多個，或者将一個程序配置設定到多個cpu。
worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000 10000000;
3）下面這個指令是指當一個nginx程序打開的最多檔案描述符數目，理論值應該是系統的最多打開檔案數（ulimit -n）與nginx程序數相除，但是nginx配置設定請求并不是那麼均勻，是以最好與ulimit -n的值保持一緻。
worker_rlimit_nofile 65535;
4）使用epoll的I/O模型，用這個模型來高效處理異步事件
use epoll;
5）每個程序允許的最多連接配接數，理論上每台nginx伺服器的最大連接配接數為worker_processes*worker_connections。
worker_connections 65535;
6）http連接配接逾時時間，預設是60s，功能是使用戶端到伺服器端的連接配接在設定的時間内持續有效，當出現對伺服器的後繼請求時，該功能避免了建立或者重建立立連接配接。切記這個參數也不能設定過大！否則會導緻許多無效的http連接配接占據着nginx的連接配接數，終nginx崩潰！
keepalive_timeout 60;
7）用戶端請求頭部的緩沖區大小，這個可以根據你的系統分頁大小來設定，一般一個請求的頭部大小不會超過1k，不過由于一般系統分頁都要大于1k，是以這裡設定為分頁大小。分頁大小可以用指令getconf PAGESIZE取得。
client_header_buffer_size 4k;
8）下面這個參數将為打開檔案指定緩存，預設是沒有啟用的，max指定緩存數量，建議和打開檔案數一緻，inactive是指經過多長時間檔案沒被請求後删除緩存。
open_file_cache max=102400 inactive=20s;
9）下面這個是指多長時間檢查一次緩存的有效資訊。
open_file_cache_valid 30s;
10）open_file_cache指令中的inactive參數時間内檔案的最少使用次數，如果超過這個數字，檔案描述符一直是在緩存中打開的，如上例，如果有一個檔案在inactive時間内一次沒被使用，它将被移除。
open_file_cache_min_uses 1;
11）隐藏響應頭中的有關作業系統和web server（Nginx）版本号的資訊，這樣對于安全性是有好處的。
server_tokens off;
12）可以讓sendfile()發揮作用。sendfile()可以在磁盤和TCP socket之間互相拷貝資料(或任意兩個檔案描述符)。Pre-sendfile是傳送資料之前在使用者空間申請資料緩沖區。之後用read()将資料從檔案拷貝到這個緩沖區，write()将緩沖區資料寫入網絡。sendfile()是立即将資料從磁盤讀到OS緩存。因為這種拷貝是在核心完成的，sendfile()要比組合read()和write()以及打開關閉丢棄緩沖更加有效(更多有關于sendfile)。
sendfile on;
13）告訴nginx在一個資料包裡發送所有頭檔案，而不一個接一個的發送。就是說資料包不會馬上傳送出去，等到資料包最大時，一次性的傳輸出去，這樣有助于解決網絡堵塞。
tcp_nopush on;
14）告訴nginx不要緩存資料，而是一段一段的發送--當需要及時發送資料時，就應該給應用設定這個屬性，這樣發送一小塊資料資訊時就不能立即得到傳回值。
tcp_nodelay on;
比如：
http {
server_tokens off;
sendfile on;
tcp_nopush on;
tcp_nodelay on;
......
}
15）用戶端請求頭部的緩沖區大小，這個可以根據系統分頁大小來設定，一般一個請求頭的大小不會超過1k，不過由于一般系統分頁都要大于1k，是以這裡設定為分頁大小。
用戶端請求頭部的緩沖區大小，這個可以根據系統分頁大小來設定，一般一個請求頭的大小不會超過1k，不過由于一般系統分頁都要大于1k，是以這裡設定為分頁大小。
分頁大小可以用指令getconf PAGESIZE取得。
[root@test-huanqiu ~]# getconf PAGESIZE
4096
但也有client_header_buffer_size超過4k的情況，但是client_header_buffer_size該值必須設定為“系統分頁大小”的整倍數。
16）為打開檔案指定緩存，預設是沒有啟用的，max 指定緩存數量，建議和打開檔案數一緻，inactive 是指經過多長時間檔案沒被請求後删除緩存。
open_file_cache max=65535 inactive=60s;
17）open_file_cache 指令中的inactive 參數時間内檔案的最少使用次數，如果超過這個數字，檔案描述符一直是在緩存中打開的，如上例，如果有一個檔案在inactive 時間内一次沒被使用，它将被移除。
18）指定多長時間檢查一次緩存的有效資訊。
open_file_cache_valid 80s;
############### 常用Nginx标準配置 ##################
[root@dev-huanqiu ~]# cat /usr/local/nginx/conf/nginx.conf
user www www;
worker_processes 8;
worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000;
error_log /www/log/nginx_error.log crit;
pid /usr/local/nginx/nginx.pid;
worker_rlimit_nofile 65535;
events
{
use epoll;
worker_connections 65535;
}
http
{
include mime.types;
default_type application/octet-stream;
charset utf-8;
server_names_hash_bucket_size 128;
client_header_buffer_size 2k;
large_client_header_buffers 4 4k;
client_max_body_size 8m;
sendfile on;
tcp_nopush on;
keepalive_timeout 60;
fastcgi_cache_path /usr/local/nginx/fastcgi_cache levels=1:2
keys_zone=TEST:10m
inactive=5m;
fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;
fastcgi_buffer_size 16k;
fastcgi_buffers 16 16k;
fastcgi_busy_buffers_size 16k;
fastcgi_temp_file_write_size 16k;
fastcgi_cache TEST;
fastcgi_cache_valid 200 302 1h;
fastcgi_cache_valid 301 1d;
fastcgi_cache_valid any 1m;
fastcgi_cache_min_uses 1;
fastcgi_cache_use_stale error timeout invalid_header http_500;
open_file_cache max=204800 inactive=20s;
open_file_cache_min_uses 1;
open_file_cache_valid 30s;
tcp_nodelay on;
gzip on;
gzip_min_length 1k;
gzip_buffers 4 16k;
gzip_http_version 1.0;
gzip_comp_level 2;
gzip_types text/plain application/x-javascript text/css application/xml;
gzip_vary on;
server
{
listen 8080;
server_name huan.wangshibo.com;
index index.php index.htm;
root /www/html/;
location /status
{
stub_status on;
}
location ~ .*\.(php|php5)?$
{
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
include fcgi.conf;
}
location ~ .*\.(gif|jpg|jpeg|png|bmp|swf|js|css)$
{
expires 30d;
}
log_format access '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" $http_x_forwarded_for';
access_log /www/log/access.log access;
}
} 二、關于FastCGI的幾個指令
1）這個指令為FastCGI緩存指定一個路徑，目錄結構等級，關鍵字區域存儲時間和非活動删除時間。
fastcgi_cache_path /usr/local/nginx/fastcgi_cache levels=1:2 keys_zone=TEST:10m inactive=5m;
2）指定連接配接到後端FastCGI的逾時時間。
fastcgi_connect_timeout 300;
3）向FastCGI傳送請求的逾時時間，這個值是指已經完成兩次握手後向FastCGI傳送請求的逾時時間。
fastcgi_send_timeout 300;
4）接收FastCGI應答的逾時時間，這個值是指已經完成兩次握手後接收FastCGI應答的逾時時間。
fastcgi_read_timeout 300;
5）指定讀取FastCGI應答第一部分 需要用多大的緩沖區，這裡可以設定為fastcgi_buffers指令指定的緩沖區大小，上面的指令指定它将使用1個 16k的緩沖區去讀取應答的第一部分，即應答頭，其實這個應答頭一般情況下都很小（不會超過1k），但是你如果在fastcgi_buffers指令中指 定了緩沖區的大小，那麼它也會配置設定一個fastcgi_buffers指定的緩沖區大小去緩存。
fastcgi_buffer_size 16k;
6）指定本地需要用多少和多大的緩沖區來 緩沖FastCGI的應答，如上所示，如果一個php腳本所産生的頁面大小為256k，則會為其配置設定16個16k的緩沖區來緩存，如果大于256k，增大 于256k的部分會緩存到fastcgi_temp指定的路徑中， 當然這對伺服器負載來說是不明智的方案，因為記憶體中處理資料速度要快于硬碟，通常這個值 的設定應該選擇一個你的站點中的php腳本所産生的頁面大小的中間值，比如你的站點大部分腳本所産生的頁面大小為 256k就可以把這個值設定為16 16k，或者4 64k 或者64 4k，但很顯然，後兩種并不是好的設定方法，因為如果産生的頁面隻有32k，如果用4 64k它會配置設定1個64k的緩沖區去緩存，而如果使用64 4k它會配置設定8個4k的緩沖區去緩存，而如果使用16 16k則它會配置設定2個16k去緩存頁面，這樣看起來似乎更加合理。
fastcgi_buffers 16 16k;
7）這個指令我也不知道是做什麼用，隻知道預設值是fastcgi_buffers的兩倍。
fastcgi_busy_buffers_size 32k;
8）在寫入fastcgi_temp_path時将用多大的資料塊，預設值是fastcgi_buffers的兩倍。
fastcgi_temp_file_write_size 32k;
9）開啟FastCGI緩存并且為其制定一個名稱。個人感覺開啟緩存非常有用，可以有效降低CPU負載，并且防止502錯誤。但是這個緩存會引起很多問題，因為它緩存的是動态頁面。具體使用還需根據自己的需求。
fastcgi_cache TEST
10）為指定的應答代碼指定緩存時間，如上例中将200，302應答緩存一小時，301應答緩存1天，其他為1分鐘。
fastcgi_cache_valid 200 302 1h;
fastcgi_cache_valid 301 1d;
fastcgi_cache_valid any 1m;
11）緩存在fastcgi_cache_path指令inactive參數值時間内的最少使用次數，如上例，如果在5分鐘内某檔案1次也沒有被使用，那麼這個檔案将被移除。
fastcgi_cache_min_uses 1;
12）不知道這個參數的作用，猜想應該是讓nginx知道哪些類型的緩存是沒用的。
fastcgi_cache_use_stale error timeout invalid_header http_500;
#########################################################
另外，FastCGI自身也有一些配置需要進行優化，如果你使用php-fpm來管理FastCGI，可以修改配置檔案中的以下值：
1）同時處理的并發請求數，即它将開啟最多60個子線程來處理并發連接配接。
<value name="max_children">60</value>
2）最多打開檔案數。
<value name="rlimit_files">65535</value>
3）每個程序在重置之前能夠執行的最多請求數。
<value name="max_requests">65535</value>
三、關于核心參數的優化，在/etc/sysctl.conf檔案内
1）timewait的數量，預設是180000。(Deven:是以如果想把timewait降下了就要把tcp_max_tw_buckets值減小)
net.ipv4.tcp_max_tw_buckets = 6000
2）允許系統打開的端口範圍。
net.ipv4.ip_local_port_range = 1024 65000
3）啟用TIME-WAIT狀态sockets快速回收功能;用于快速減少在TIME-WAIT狀态TCP連接配接數。1表示啟用;0表示關閉。但是要特别留意的是：這個選項一般不推薦啟用，因為在NAT(Network Address Translation)網絡下，會導緻大量的TCP連接配接建立錯誤，進而引起網站通路故障。
net.ipv4.tcp_tw_recycle = 0
=================================================================================
實際上，net.ipv4.tcp_tw_recycle功能的開啟，一般需要net.ipv4.tcp_timestamps（一般系統預設是開啟這個功能的）這個開關開啟後才有效果；
當tcp_tw_recycle 開啟時（tcp_timestamps 同時開啟，快速回收 socket 的效果達到），對于位于NAT裝置後面的 Client來說，是一場災難！！會導緻到NAT裝置後面的Client連接配接Server不穩定（有的 Client 能連接配接 server，有的 Client 不能連接配接 server）。
tcp_tw_recycle這個功能，其實是為内部網絡（網絡環境自己可控 ” -不存在NAT 的情況）設計的，對于公網環境下，不宜使用。通常來說，回收TIME_WAIT狀态的socket是因為“無法主動連接配接遠端”，因為無可用的端口，而不應該是要回收記憶體（沒有必要）。也就是說，需求是Client的需求，Server會有“端口不夠用”的問題嗎？除非是前端機，需要大量的連接配接後端服務，也就是充當着Client的角色。
正确的解決這個總是辦法應該是：
net.ipv4.ip_local_port_range = 9000 6553 #預設值範圍較小
net.ipv4.tcp_max_tw_buckets = 10000 #預設值較小，還可适當調小
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 10
4）開啟重用功能，允許将TIME-WAIT狀态的sockets重新用于新的TCP連接配接。這個功能啟用是安全的，一般不要去改動！
net.ipv4.tcp_tw_reuse = 1
5）開啟SYN Cookies，當出現SYN等待隊列溢出時，啟用cookies來處理。
net.ipv4.tcp_syncookies = 1
6）web應用中listen函數的backlog預設會給我們核心參數的net.core.somaxconn限制到128，而nginx定義的NGX_LISTEN_BACKLOG預設為511，是以有必要調整這個值。
net.core.somaxconn = 262144
7）每個網絡接口接收資料包的速率比核心處理這些包的速率快時，允許送到隊列的資料包的最大數目。
net.core.netdev_max_backlog = 262144
8）系統中最多有多少個TCP套接字不被關聯到任何一個使用者檔案句柄上。如果超過這個數字，孤兒連接配接将即刻被複位并列印出警告資訊。這個限制僅僅是為了防止簡單的DoS攻擊，不能過分依靠它或者人為地減小這個值，更應該增加這個值(如果增加了記憶體之後)。
net.ipv4.tcp_max_orphans = 262144
9）記錄的那些尚未收到用戶端确認資訊的連接配接請求的最大值。對于有128M記憶體的系統而言，預設值是1024，小記憶體的系統則是128。
net.ipv4.tcp_max_syn_backlog = 262144
10）時間戳可以避免序列号的卷繞。一個1Gbps的鍊路肯定會遇到以前用過的序列号。時間戳能夠讓核心接受這種“異常”的資料包。
net.ipv4.tcp_timestamps = 1
=============================================================================
有不少伺服器為了提高性能，開啟net.ipv4.tcp_tw_recycle選項，在NAT網絡環境下，容易導緻網站通路出現了一些connect失敗的問題。
個人建議：
關閉net.ipv4.tcp_tw_recycle選項，而不是net.ipv4.tcp_timestamps；
因為在net.ipv4.tcp_timestamps關閉的條件下，開啟net.ipv4.tcp_tw_recycle是不起作用的；而net.ipv4.tcp_timestamps可以獨立開啟并起作用。
=============================================================================
11）為了打開對端的連接配接，核心需要發送一個SYN并附帶一個回應前面一個SYN的ACK。也就是所謂三次握手中的第二次握手。這個設定決定了核心放棄連接配接之前發送SYN+ACK包的數量。
net.ipv4.tcp_synack_retries = 1
12）在核心放棄建立連接配接之前發送SYN包的數量。
net.ipv4.tcp_syn_retries = 1
13）如果套接字由本端要求關閉，這個參數 決定了它保持在FIN-WAIT-2狀态的時間。對端可以出錯并永遠不關閉連接配接，甚至意外當機。預設值是60秒。2.2 核心的通常值是180秒，你可以按這個設定，但要記住的是，即使你的機器是一個輕載的WEB伺服器，也有因為大量的死套接字而記憶體溢出的風險，FIN- WAIT-2的危險性比FIN-WAIT-1要小，因為它最多隻能吃掉1.5K記憶體，但是它們的生存期長些。
net.ipv4.tcp_fin_timeout = 30
14）當keepalive起用的時候，TCP發送keepalive消息的頻度。預設是2小時。
net.ipv4.tcp_keepalive_time = 30
=====================================================================
以下是一個常用的核心參數的标準配置
[root@dev-huanqiu ~]# cat /etc/sysctl.conf
net.ipv4.ip_forward = 0
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0
kernel.sysrq = 0
kernel.core_uses_pid = 1
net.ipv4.tcp_syncookies = 1 //這四行标紅内容，一般是發現大量TIME_WAIT時的解決辦法
kernel.msgmnb = 65536
kernel.msgmax = 65536
kernel.shmmax = 68719476736
kernel.shmall = 4294967296
net.ipv4.tcp_sack = 1
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_rmem = 4096 87380 4194304
net.ipv4.tcp_wmem = 4096 16384 4194304
net.core.wmem_default = 8388608
net.core.rmem_default = 8388608
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_max_orphans = 3276800
net.ipv4.tcp_timestamps = 1 //在net.ipv4.tcp_tw_recycle設定為1的時候，這個選擇最好加上
net.ipv4.tcp_tw_recycle = 1 //開啟此功能可以減少TIME-WAIT狀态，但是NAT網絡模式下打開有可能會導緻tcp連接配接錯誤，慎重。
net.ipv4.tcp_mem = 94500000 915000000 927000000
net.ipv4.ip_conntrack_max = 6553500
############## tcp參數引起的一個nginx故障 #############
net.ipv4.tcp_tw_recycle = 1 這個功能打開後，确實能減少TIME-WAIT狀态，習慣上我都會将這個參數打開。
但是也因為這個參數踩過一次坑：
公司的一個釋出新聞的CMS背景系統，采用haproxy+keepalived代理架構，後端的real server伺服器外網ip全部拿掉。
現象：在某一天早上發文高峰期，CMS背景出現通路故障，重新開機php服務後會立刻見效，但持續一段時間後，通路就又出現故障。
排查nginx和php日志也沒有發現什麼，後來google了一下，發現就是net.ipv4.tcp_tw_recycle這個參數搗的鬼！
這種網絡架構對于後端的realserver來說是NAT模式，打開這個參數後，會導緻大量的TCP連接配接建立錯誤，進而引起網站通路故障。
最後将net.ipv4.tcp_tw_recycle設定為0，關閉這個功能後，背景通路即刻恢複正常
############# Nginx安全配置小提示 #############
下面是一個常見安全陷阱和解決方案的清單，它可以輔助來確定你的Nginx部署是安全的。
1）禁用autoindex子產品。這個可能在你使用的Nginx版本中已經更改了，如果沒有的話隻需在配置檔案的location塊中增加autoindex off;聲明即可。
2）禁用伺服器上的ssi (伺服器端引用)。這個可以通過在location塊中添加ssi off; 。
3）關閉伺服器标記。如果開啟的話（預設情況下）所有的錯誤頁面都會顯示伺服器的版本和資訊。将server_tokens off;聲明添加到Nginx配置檔案來解決這個問題。
4）在配置檔案中設定自定義緩存以限制緩沖區溢出攻擊的可能性。
client_body_buffer_size 1K;
client_header_buffer_size 1k;
client_max_body_size 1k;
large_client_header_buffers 2 1k;
5）将timeout設低來防止DOS攻擊。所有這些聲明都可以放到主配置檔案中。
client_body_timeout 10;
client_header_timeout 10;
keepalive_timeout 65;
send_timeout 10;
6）限制使用者連接配接數來預防DOS攻擊。
limit_zone slimits $binary_remote_addr 5m;
limit_conn slimits 5;
7）試着避免使用HTTP認證。HTTP認證預設使用crypt，它的哈希并不安全。如果你要用的話就用MD5（這也不是個好選擇但負載方面比crypt好） 。 ############# 總結：Nginx調優方式 #############
1、隐藏 Nginx 版本号（server_tokens off）
2、隐藏 Nginx 版本号和軟體名（進入nginx的源碼包裡修改）
3、更改 Nginx 服務的預設使用者
4、優化 Nginx worker 程序數
5、綁定 Nginx 程序到不同的 CPU 上
6、優化 Nginx 處理事件模型
7、優化 Nginx 單個程序允許的最大連接配接數
8、優化 Nginx worker 程序最大打開檔案數
9、優化伺服器域名的散清單大小
10、開啟高效檔案傳輸模式
11、優化 Nginx 連接配接逾時時間
12、限制上傳檔案的大小
13、FastCGI 相關參數調優
14、配置 Nginx gzip 壓縮
15、配置 Nginx expires 緩存
16、優化 Nginx日志(日志切割)
17、優化 Nginx 站點目錄
18、配置 Nginx 防盜鍊
19、配置 Nginx 錯誤頁面優雅顯示
20、優化 Nginx 檔案權限
21、Nginx 防爬蟲優化
22、控制 Nginx 并發連接配接數
23、叢集代理優化
############# 運維中常用Nginx監控與性能調優做法 #############
1. Nginx監控
nginx有自帶的監控子產品，編譯nginx的時候,加上參數 --with-http_stub_status_module
# 配置指令
./configure --prefix=/usr/local
--user=nginx
--group=nginx
--with-http_ssl_module
--with-http_realip_module
--http-client-body-temp-path=/usr/local/var/tmp/nginx/client
--http-proxy-temp-path=/usr/local/var/tmp/nginx/proxy
--http-fastcgi-temp-path=/usr/local/var/tmp/nginx/fcgi
--http-scgi-temp-path=/usr/local/var/tmp/nginx/scgi
--http-uwsgi-temp-path=/usr/local/var/tmp/nginx/uwsgi
--with-http_geoip_module
--with-http_stub_status_module 接着修改nginx配置檔案，添加監控狀态配置
location = /nginx_status {
stub_status on;
access_log off;
allow 127.0.0.1;
deny all;
} 最後就可以通過 "curl 127.0.0.1/nginx_status"通路nginx的狀态了。
安裝python-pip
# yum install epel-release
# yum install python-pip
安裝ngxtop
# pip install ngxtop
ngxtop常用指令：
# ngxtop top remote_addr 檢視通路最多的IP
# ngxtop -i 'status >= 400' print request status http_referer #列出4xx or 5xx 的相應
指定配置檔案: # ngxtop -c /etc/nginx/nginx.conf
查詢狀态是200：# ngxtop -c /etc/nginx/nginx.conf -i 'status==200'
查詢通路最多ip: # ngxtop -c /etc/nginx/nginx.conf -g remote_addr 1）配置線程數和并發數 #############################
worker_processes 4 #cpu(取決于cpu的核數，一般為cpu核數或倍數。也可以配置成auto，讓nginx自己選擇工作線程數)
events{
worker_connections 10240; #每一個程序打開的最大連接配接數，包含了nginx與用戶端和nginx與upstream之間的連接配接（受限于作業系統）
multi_accept on; #可以一次建立多個連接配接
use epoll; # Linux下多路複用IO接口select/poll的增強版本，它能顯著提高程式在大量并發連接配接中隻有少量活躍的情況下的系統CPU使用率
}
2）配置後端Server的長連接配接 #############################
upstream server_pool{
server localhost:8080 weight=1 max_fails=2 fail_timeout=30s;
server localhost:8081 weight=1 max_fails=2 fail_timeout=30s;
keepalive 300; #300個長連接配接
}
location /{
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_pass http://server_pool/;
}
3) 啟用緩存、壓縮。Nginx的緩存還有很大的局限性，下面是靜态檔案壓縮配置 #############################
gzip on;
gzip_disable "msie6";
gzip_proxied any;
gzip_min_length 1000;
gzip_comp_level 6;
gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript;
4）其他優化 #############################
sendfile on; #減少檔案在應用和核心之間的拷貝
tcp_nopush on; #當資料包達到一定大小再發送
tcp_nodelay off; #有資料随時發送（隻用在應答需要非常快速的情況下
注意：測試nginx文法是否正确：nginx -t
5) 作業系統優化 #############################
1. 配置檔案/etc/sysctl.conf
sysctl -w net.ipv4.tcp_syncookies=1 #防止一個套接字在有過多試圖連接配接到達時引起過載
sysctl -w net.core.somaxconn=1024 #預設128，連接配接隊列
sysctl -w net.ipv4.tcp_fin_timeout=10 #timewait的逾時時間
sysctl -w net.ipv4.tcp_tw_reuse=1 #os直接使用timevait的連接配接
sysctl -w net.ipv4.tcp_tw_recycle=0 #回收禁用
2. 配置檔案/etc/security/limits.conf
hard nofile 204800
soft nofile 204800
soft core unlimited
soft stack 204800 ![（Nginx）03_Nginx原理與優化一、Nginx原理二、master-workers機制三、面試題：[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)