nginx 進程數,建議按照cpu 數目來指定,可是也能夠直接指定爲auto。nginx
爲每一個進程分配cpu,上例中將8 個進程分配到8 個cpu,固然能夠寫多個,或者將一
個進程分配到多個cpu。
參考:https://blog.csdn.net/u011957758/article/details/50959823web
這個指令是指當一個nginx 進程打開的最多文件描述符數目,理論值應該是最多打開文
件數(ulimit -n)與nginx 進程數相除,可是nginx 分配請求並非那麼均勻,因此最好與ulimit -n 的值保持一致。瀏覽器
使用epoll的I/O模型;epoll是多路複用IO(I/O Multiplexing)中的一種方式服務器
每一個進程容許的最多鏈接數,理論上每臺nginx服務器的最大鏈接數爲worker_processes*worker_connections。cookie
HTTP 有一個 KeepAlive 模式,它告訴 webserver 在處理完一個請求後保持這個 TCP 鏈接的打開狀態。若接收到來自客戶端的其它請求,服務端會利用這個未被關閉的鏈接,而不須要再創建一個鏈接。
Nginx 使用 keepalive_timeout 來指定 KeepAlive 的超時時間(timeout)。指定每一個 TCP 鏈接最多能夠保持多長時間。Nginx 的默認值是 75 秒,有些瀏覽器最多隻保持 60 秒,因此能夠設定爲 60 秒。若將它設置爲 0,就禁止了 keepalive 鏈接。網絡
客戶端請求頭部的緩衝區大小,這個能夠根據你的系統分頁大小來設置,通常一個請求的頭部大小不會超過1k,不過因爲通常系統分頁都要大於1k,因此這裏設置爲分頁大小。分頁大小能夠用命令getconf PAGESIZE取得。socket
timewait 的數量,默認是180000。tcp
容許系統打開的端口範圍。ide
啓用timewait 快速回收。函數
開啓重用。容許將TIME-WAIT sockets 從新用於新的TCP 鏈接。
開啓SYN Cookies,當出現SYN 等待隊列溢出時,啓用cookies 來處理。
web 應用中listen 函數的backlog 默認會給咱們內核參數的net.core.somaxconn 限制到128,而nginx 定義的NGX_LISTEN_BACKLOG 默認爲511,因此有必要調整這個值。
每一個網絡接口接收數據包的速率比內核處理這些包的速率快時,容許送到隊列的數據包的最大數目。
系統中最多有多少個TCP 套接字不被關聯到任何一個用戶文件句柄上。若是超過這個數字,孤兒鏈接將即刻被複位並打印出警告信息。這個限制僅僅是爲了防止簡單的DoS ***,不能過度依靠它或者人爲地減少這個值,更應該增長這個值(若是增長了內存以後)。
記錄的那些還沒有收到客戶端確認信息的鏈接請求的最大值。對於有128M 內存的系統而言,缺省值是1024,小內存的系統則是128。
時間戳能夠避免序列號的卷繞。一個1Gbps 的鏈路確定會遇到之前用過的序列號。時間戳可以讓內核接受這種「異常」的數據包。這裏須要將其關掉。
爲了打開對端的鏈接,內核須要發送一個SYN 並附帶一個迴應前面一個SYN 的ACK。也就是所謂三次握手中的第二次握手。這個設置決定了內核放棄鏈接以前發送SYN+ACK 包的數量。
在內核放棄創建鏈接以前發送SYN 包的數量。
如 果套接字由本端要求關閉,這個參數決定了它保持在FIN-WAIT-2 狀態的時間。對端能夠出錯並永遠不關閉鏈接,甚至意外當機。缺省值是60 秒。2.2 內核的一般值是180 秒,3你能夠按這個設置,但要記住的是,即便你的機器是一個輕載的WEB 服務器,也有由於大量的死套接字而內存溢出的風險,FIN- WAIT-2 的危險性比FIN-WAIT-1 要小,由於它最多隻能吃掉1.5K 內存,可是它們的生存期長些。
當keepalive 起用的時候,TCP 發送keepalive 消息的頻度。缺省是2 小時。