淺談Nginx效能調優

安全劍客發表於2020-12-17
導讀 Nginx能夠最佳化的地方非常多,本文只涉及到了其中很小的一些方面,但也足夠滿足我們的使用場景了。

淺談Nginx效能調優淺談Nginx效能調優

  引數最佳化

下文中提到的一些配置,需要較新的 (2.6以上)核心才能夠支援,筆者使用的  7.4,核心版本3.10,如果不滿足需要的話,最好進行相應的升級,畢竟打補丁是件費力不討好的事情。對於系統層面的調優,通常我們修改檔案描述符限制、緩衝區佇列長度以及臨時埠數量就可以了。

檔案描述符限制

由於每個TCP連線都要佔用一個檔案描述符,一旦檔案描述符耗盡,新的連線到來就會返回“Too many open files”這樣的錯誤,為了提高效能,我們需要對其進行修改:1.系統層級的限制 編輯檔案 /etc/sysctl.conf,新增如下內容:

 fs.file-max =10000000
 fs.nr_open =10000000

使用者層級的限制 編輯檔案 /etc/security/limits.conf,新增以下內容:

  *      hard   nofile      1000000
  *      soft   nofile      1000000

這裡我們保證使用者層級限制不大於系統層級限制就可以了,否則可能會出現無法透過SSH登入的問題。修改完畢執行如下 :

 $ sysctl -p

可以透過執行  ulimit -a檢視是否修改成功。

TCP連線佇列長度

編輯檔案 /etc/sysctl.conf,新增如下內容:

 # The length of the syn quene net.ipv4.tcp_max_syn_backlog =65535 # The length of the tcp accept queue net.core.somaxconn =65535

其中 tcp_max_syn_backlog用於指定半連線SYN佇列長度,當新連線到來時,系統會檢測半連線SYN佇列,如果佇列已滿,則無法處理該SYN請求,並在 /proc/net/netstat中的 ListenOverflows和 ListenDrops中增加統計計數somaxconn用於指定全連線ACCEPT佇列長度,當該佇列滿了以後,客戶端傳送的ACK包將無法被正確處理,並返回錯誤"connection reset by peer"Nginx則會記錄一條error日誌"no live upstreams while connecting to upstreams"如果出現以上錯誤,我們需要考慮增大這兩項的配置。

臨時埠

由於Nginx用作代理,每個到上游Web服務的TCP連線都要佔用一個臨時埠,因此我們需要修改 ip_local_port_range引數 修改 /etc/sysctl.conf檔案,新增如下內容:

 net.ipv4.ip_local_port_range =102465535
 net.ipv4.ip_local_reserved_ports =8080,8081,9000-9010

其中,引數 ip_local_reserved_ports用於指定保留埠,這是為了防止服務埠被佔用而無法啟動。

Nginx引數最佳化

Nginx引數最佳化主要圍繞 nginx.conf這個配置檔案展開,下文不再贅述。

工作程式

Nginx效能強大的一個重要原因在於它採用多程式非阻塞I/O模型,因此我們要妥善利用這一點:

  •  worker_processes  預設的Nginx只有一個master程式一個worker程式,我們需要對其進行修改,可以設定為指定的個數,也可以設定為 auto,即系統的CPU核數。更多的worker數量將導致程式間競爭cpu資源,從而帶來不必要的上下文切換。因此這裡我們將它設定為cpu的核數即可:    worker_processes   auto
  •  worker_connections 每個worker可以處理的併發連線數,預設值512不是很夠用,我們適當將它增大:    worker_connections 4096
  •  Nginx支援以下I/O複用方法處理連線:select、 poll、 kqueue、 epoll、 rtsig、 /dev/poll、 eventport。它們分別適用於不同的作業系統,其中 epoll是Linux系統上面效率最高的:    use epoll

KeepAlive

為了避免從Nginx到Web服務頻繁的建立、斷開連線,我們可以啟用從HTTP 1.1開始支援的KeepAlive長連線特性,它可以大幅減少CPU和網路開銷,在我們的實戰中也是對效能提高最大的一環。keepalive必須和 proxy_http_version與 proxy_set_header結合使用, 參考配置如下:

 upstream BACKEND {
     keepalive 300;
      server 127.0.0.1:8081;
  }
 server {
      listen 8080;
     location /{
         proxy_pass 
         proxy_http_version 1.1;
         proxy_set_header Connection"";
  }
 }

其中 keepalive既非timeout,也不是連線池數量,官方解釋如下:

The connections parameter sets the maximum number of idle keepalive connections to upstream servers that are preserved in the cache of each worker process. When this number is exceeded, the least recently used connections are closed.

可以看出它的意思是“最大空閒長連線數量”,超出這個數量的空閒長連線將被回收,當請求數量穩定而平滑時,空閒長連線數量將會非常小(接近於0),而現實中請求數量是不可能一直平滑而穩定的,當請求數量有波動時,空閒長連線數量也隨之波動:

  1.  當空閒長連線數量大於配置值時,將會導致大於配置值的那部分長連線被回收;
  2.  當長連線不夠用時,將會重新建立新的長連線。

因此,如果這個值過小的話,就會導致連線池頻繁的回收、分配、再回收。為了避免這種情況出現,可以根據實際情況適當調整這個值,在我們實際情況中,目標QPS為6000,Web服務響應時間約為200ms,因此需要約1200個長連線,而 keepalive值取長連線數量的10%~30%就可以了,這裡我們取300,如果不想計算,直接設為1000也是可行的。

Access-Log快取

記錄日誌的I/O開銷比較高,好在Nginx支援日誌快取,我們可以利用這個功能,降低寫日誌檔案的頻率,從而提高效能。可以將 buffer和 flush兩個引數結合使用來控制快取行為:

  access_log /var/logs/nginx-access.log buffer=64k gzip flush=1m

其中 buffer制定了快取大小,當緩衝區達到 buffer所指定的大小時,Nginx就會將快取起來的日誌寫到檔案中;flush指定了快取超時時間,當 flush指定的時間到達時,也會觸發快取日誌寫入檔案操作。

檔案描述符限制

上一節中已經對Linux系統的檔案描述符限制進行了修改,Nginx配置中同樣有相應的配置項:worker_rlimit_nofile, 理論上這個值應該設定為 /etc/security/limits.conf 中的值除以 worker_processes, 但實際中不可能每個程式均勻分配,所以這裡只要設定成和 /etc/security/limits.conf 一樣就可以了

 worker_rlimit_nofile 1000000;

總結

以上就是筆者進行Nginx調優的一些經驗,可以看出基本是圍繞Nginx的Error日誌展開的,之後又對一些比較大的效能瓶頸進行了一些改進。Nginx能夠最佳化的地方非常多,本文只涉及到了其中很小的一些方面,但也足夠滿足我們的使用場景了。

原文來自:

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69955379/viewspace-2743205/,如需轉載,請註明出處,否則將追究法律責任。

相關文章