Nginx 壓測和性能分析的一些經驗

[TOC]

Nginx 壓測和性能分析的一些經驗

Nginx 壓測的一些經驗

關注網卡帶寬、網卡隊列

• 單個千兆網卡的機器，去壓測 nginx 的性能，會存在帶寬的瓶頸，這個時候觀察 CPU 和帶寬，發現 CPU 沒有跑滿，si 也沒有滿，可是網卡帶寬流量已經達到了瓶頸，對於千兆網卡這個說的小 b，而不是大 B；而後理論上千兆網卡的上限是 128MB/s，可是因爲種種因素，通常很難達到 128，可是通常而言到了 110MB/s 以上就已是瓶頸了。

  • 千兆網卡基礎上，網卡會存在瓶頸，在這個基礎上Nginx 當作 Web Server 的話，針對 http：

    • 0KB，QPS = 48w (return 200)
    • 0KB，QPS = 29w (return 302)
    • 1B， QPS = 23w
    • 1KB，QPS = 9w

  • Nginx 直接 return 200 和 return 302，QPS 相差不少（千兆網卡基礎上）

    • 在千兆網卡上， return 200， QPS 48w；return 302， QPS 29w。緣由是由於 return 302 的返回結果的 Response 的數據量要大些，從而致使致使了每秒中處理不了那麼多請求，由於網卡流量存在瓶頸

• 當壓測端的網卡有 4 個千兆網卡了以後，施壓端的網卡流量就到瓶頸了，這個時候就須要調整施壓端了。

• 4 個網卡綁定後，壓測短鏈接的時候，發現 si 已經到 100%，而且是固定的幾個 CPU，這個就說明網卡綁定重複了。

  • 網卡從新綁定沒有重複以後，si 有改善，總體性能也稍有提升

• 單機 24 核下，單千兆網卡的場景下，網卡先出現瓶頸； 4 個千兆網卡的場景下，CPU si 軟中斷先出現瓶頸。

• 壓測時候，要關注大包、小包的不一樣處理，對於小包，CPU 消耗會更多，由於軟中斷問題、解包頭、校驗包數據等層面的問題。 sar 觀察數據的時候，通常而言，rxpck/s 和 txpck/s 只須要關注數據而不會存在瓶頸，這個的瓶頸會創建在 CPU 上；而須要關注的是 rxkB/s 和 txkB/s ，這個決定了網卡流量帶寬的上限。不只僅是要觀察服務端，還要看客戶端是否有瓶頸（CPU、網卡帶寬）、錯誤狀況等

關注 Nginx CPU 消耗是否均勻

• 正常而言，nginx 的各個 worker 進程的 CPU 消耗應該都要比較均勻，若是相差 10% 以上，甚至 20% 以上，那麼就必定存在 CPU 消耗不均的問題。nginx 目前的版本會使得 CPU 不均，由於關閉了 accept_mutex，正常的話，各個 worker 進程應該都是要差很少的 CPU 消耗，若是開啓accept_mutex on；會均勻到前面幾個 nginx worker 進程。

• 最優的姿式是開啓 reuseport，可是這個須要注意要和 dynamic upstream 一塊兒使用，不然若是出現頻繁 reload 則會致使出現大量 RST。

關注 CPU 超線程

• 禁能、使能 CPU 超線程，在 nginx 單進程的狀況下，並無明顯差別
  • 壓測時候， 是否關閉超線程，沒有明顯差別

關注單機多實例

• 單機單實例性能達到極限後或者出現瓶頸後，單機多實例仍是同樣，沒有提高； 單機單實例沒有性能瓶頸的話，多實例能夠提高性能

關注施壓端

• 壓測的時候，要找到一個性能拐點；若是一上來就是瓶頸了，那麼還須要往回調，直到找到一個最佳的性能拐點。

  • 長鏈接的時候，若是 wrk 給的線程數、併發數太大，反而會使得 Nginx 只有 1 個 worker 進程的時候的性能下降； 短進程的時候，wrk 端的系統參數 net.ipv4.tcp_tw_recycle 要設置爲 1，讓端口複用，不然會出現一些鏈接錯誤

  • 所以一個過程就是會將施壓端的壓力（線程數、併發數）會減小、增大，從而觀察 Nginx 服務端的數據，而後獲得最佳性能數據

• wr 壓力上不去? 要想爲啥上不去？ CPU遇到瓶頸了，仍是內存遇到瓶頸了？ 若是cpu的話，那麼怎麼給更多CPU？固然的線程數。可是線程數也要和施壓方的CPU核心數匹配。

  • top -H 看線程，要讓每一個線程都沒跑滿，這樣才能發揮最大的性能，若是每一個線程跑滿了，那麼wrk則沒法發揮最大性能，也就是沒法提供最高壓力。若是每一個線程都沒跑滿，可是QPS 仍是上不去，那麼就是Nginx這邊性能的問題了。

壓測時必需要觀察的指標

CPU【top】

top ，觀察 CPU 消耗狀況，同時也要觀察每一個 CPU 核數的狀況，而且關注 si 軟中斷的數據，si 到了 100% 就有問題了

網卡帶寬【sar -n DEV 1 100 |grep em1】

sar -n DEV 1 100 |grep em1

觀察網卡帶寬狀況，看網卡帶寬是否到了瓶頸

而後能夠 ifconfig 查看是否有丟包之類的。

每秒建連數【netstat -s |grep active】

netstat -s |grep active
    6262441249 active connections openings
複製代碼

經過 netstat -s |grep active 獲取當前活躍的鏈接，而後作差值。

5W 短鏈接的 QPS， 若是還有upstream是短鏈接，那麼每秒建連數應該是10W左右

鏈接隊列 【ss -lnt 】

ss -lnt

ss -lnt |grep -E ":6001|:6002"

State       Recv-Q Send-Q                                   Local Address:Port                                                  Peer Address:Port
複製代碼

• 當套接字處於監聽狀態（Listening）時，

  • Recv-Q 表示 syn backlog 的當前值。
  • Send-Q 表示最大的 syn backlog 值。

• 鏈接隊列若是過小，那麼須要調整系統和 nginx 的配置

磁盤 IO

Nginx 調優的一些經驗

Nginx 的性能指標

相關基礎指標：

• Requests per second (RPS) ： nginx 每秒處理的請求數（也就是： QPS）

  • RPS for HTTP Requests： nginx 每秒處理的 http 請求數

  • RPS for HTTPS Requests (SSL/TLS transactions per second )(TPS) ： nginx 每秒處理的 https 請求數

  • 要關注響應數據在 0 - 1 - 10 - 100 KB 的不一樣狀況的表現

    • 0KB 表示一個空的 http 響應，好比返回 302 錯誤碼

• Connections per Second (CPS) ： nginx 每秒處理的新建鏈接請求數

  • 包括 http 和 https

• Throughput：吞吐量，反應 nginx 能夠處理的數據量的大小的能力

• latency： 延遲和延遲分佈

其餘關注點：

• 關注 CPU 核數從 1 - n 下，nginx 性能的表現

  • 利用 taskset，能夠將一個 wrk 進程綁定到一個 CPU 核上；能夠準確的測試不一樣 CPU 核下的性能狀況

• 關注 nginx 的角色是 webserver 或者 反向代理的不一樣表現

• 鏈接數，有時候也會被稱爲併發數，指的是同時在服務中的請求數。也就是那些已經發送請求（Request），可是尚未收完應答（Response）的請求數量。

Nginx 必需要調整的參數

Nginx 必需要調整的參數：

worker_processes     auto;
worker_rlimit_nofile 10240;

worker_connections 10240;

tcp_nopush  on;
tcp_nodelay on;


keepalive_timeout  300s;     
keepalive_requests 1000000;
複製代碼

建議調整的參數：

proxy_connect_timeout 60;
proxy_send_timeout 60;
proxy_read_timeout 60;
複製代碼

Linux 系統必需要調整的參數

conntrack 參數

通常，設置 nf_conntrack_max 爲 200w， nf_conntrack_buckets 爲 1/4 或者 1/2 倍 nf_conntrack_max，防止桶太大致使性能影響。

[wdb@BJZW-K8SM-ZW-1-23-25.meitu-inc.com ingress]$ cat /proc/sys/net/netfilter/nf_conntrack_buckets
524288

[wdb@BJZW-K8SM-ZW-1-23-25.meitu-inc.com ingress]$ cat /proc/sys/net/netfilter/nf_conntrack_max
2097152
複製代碼

backlog 隊列

• net.core.somaxconn

  • 能夠排隊等待 Nginx 接受的最大鏈接數。一般若是過小致使了 Nginx 性能問題能夠查看內核日誌發現這個狀態
  • 配合 NGINX listen 指令一塊兒調整。

• net.core.netdev_max_backlog

  • 數據包在發送給 CPU 以前被網卡緩衝的速率；增長該值能夠提升具備高帶寬的機器的性能

echo 32768 > /proc/sys/net/core/somaxconn
echo 819200 > /proc/sys/net/ipv4/tcp_max_syn_backlog
複製代碼

文件描述符

• sys.fs.file-max

  • Linux 系統容許的最大文件描述數

• nofile

  • 應用層面容許的最大文件描述符數，通常設置 /etc/security/limits.conf文件

端口 【修改 /etc/sysctl.conf，而後 sysctl -p 生效】

• net.ipv4.ip_local_port_range

  • port 端口的範圍

• 對壓測端而言，若是是短連接

  • net.ipv4.tcp_tw_reuse = 1
    • 表示開啓端口複用。容許將TIME-WAIT sockets從新用於新的 TCP接，默認爲0，表示關閉；
  • net.ipv4.tcp_tw_recycle = 1
    • 表示開啓TCP鏈接中TIME-WAIT sockets的快速回收，默認爲0，表示關閉。

網卡隊列、CPU 軟中斷 si

• 單機 20-24 核下，單千兆網卡的場景下，網卡先出現瓶頸； 4 個千兆網卡的場景下，CPU si 軟中斷先出現瓶頸。

• 4 個網卡綁定後，壓測短鏈接的時候，發現 si 已經到 100%，而且是固定的幾個 CPU，這個就說明網卡綁定重複了。網卡從新綁定沒有重複以後，si 有改善，總體性能也稍有提升

• CPU idle 爲 0 不會有問題，只有 si 爲 100% 纔會有問題

  • si 到 100%，表示 CPU 在大量處理軟中斷，這個時候，說明網卡軟中斷和 CPU 綁定這個有些瓶頸。要麼就是網卡隊列不夠，要麼就是 CPU 核心太少，要麼就是網卡隊列和 cpuset 對進程的 CPU 綁定重複了。

【"歡迎關注個人微信公衆號：Linux 服務端系統研發，後面會大力經過微信公衆號發送優質文章"】