運維排障記：一次百萬長連接壓測Nginx內存溢出問題
在最近的一次百萬長連接壓測中，32C 128G 的四臺 Nginx 頻繁出現 OOM，出現問題時的內存監控如下所示。
排查的過程記錄如下。
現象描述
這是一個 websocket 百萬長連接收發消息的壓測環境，客戶端 jmeter 用了上百臺機器，經過四臺 Nginx 到后端服務，簡化后的部署結構如下圖所示。
在維持百萬連接不發數據時，一切正常，Nginx 內存穩定。在開始大量收發數據時，Nginx 內存開始以每秒上百 M 的內存增長，直到占用內存接近 128G，woker 進程開始頻繁 OOM 被系統殺掉。32 個 worker 進程每個都占用接近 4G 的內存。dmesg -T 的輸出如下所示。
- [Fri Mar 13 18:46:44 2020] Out of memory: Kill process 28258 (nginx) score 30 or sacrifice child
- [Fri Mar 13 18:46:44 2020] Killed process 28258 (nginx) total-vm:1092198764kB, anon-rss:3943668kB, file-rss:736kB, shmem-rss:4kB
work 進程重啟后，大量長連接斷連，壓測就沒法繼續增加數據量。
排查過程分析
拿到這個問題，首先查看了 Nginx 和客戶端兩端的網絡連接狀態，使用 ss -nt 命令可以在 Nginx 看到大量 ESTABLISH 狀態連接的 Send-Q 堆積很大，客戶端的 Recv-Q 堆積很大。Nginx 端的 ss 部分輸出如下所示。
- State Recv-Q Send-Q Local Address:Port Peer Address:Port
- ESTAB 0 792024 1.1.1.1:80 2.2.2.2:50664
- ...
在 jmeter 客戶端抓包偶爾可以看到較多零窗口，如下所示。
到了這里有了一些基本的方向，首先懷疑的就是 jmeter 客戶端處理能力有限，有較多消息堆積在中轉的 Nginx 這里。
為了驗證想法，想辦法 dump 一下 nginx 的內存看看。因為在后期內存占用較高的狀況下，dump 內存很容易失敗，這里在內存剛開始上漲沒多久的時候開始 dump。
首先使用 pmap 查看其中任意一個 worker 進程的內存分布，這里是 4199，使用 pmap 命令的輸出如下所示。
- pmap -x 4199 | sort -k 3 -n -r
- 00007f2340539000 475240 461696 461696 rw--- [ anon ]
- ...
隨后使用 cat /proc/4199/smaps | grep 7f2340539000 查找某一段內存的起始和結束地址，如下所示。
- cat /proc/3492/smaps | grep 7f2340539000
- 7f2340539000-7f235d553000 rw-p 00000000 00:00 0
隨后使用 gdb 連上這個進程，dump 出這一段內存。
- gdb -pid 4199
- dump memory memory.dump 0x7f2340539000 0x7f235d553000
隨后使用 strings 命令查看這個 dump 文件的可讀字符串內容，可以看到是大量的請求和響應內容。
這樣堅定了是因為緩存了大量的消息導致的內存上漲。隨后看了一下 Nginx 的參數配置，
- location / {
- proxy_pass http://xxx;
- proxy_set_header X-Forwarded-Url "$scheme://$host$request_uri";
- proxy_redirect off;
- proxy_http_version 1.1;
- proxy_set_header Upgrade $http_upgrade;
- proxy_set_header Connection "upgrade";
- proxy_set_header Cookie $http_cookie;
- proxy_set_header Host $host;
- proxy_set_header X-Forwarded-Proto $scheme;
- proxy_set_header X-Real-IP $remote_addr;
- proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
- client_max_body_size 512M;
- client_body_buffer_size 64M;
- proxy_connect_timeout 900;
- proxy_send_timeout 900;
- proxy_read_timeout 900;
- proxy_buffer_size 64M;
- proxy_buffers 64 16M;
- proxy_busy_buffers_size 256M;
- proxy_temp_file_write_size 512M;
- }
可以看到 proxy_buffers 這個值設置的特別大。接下來我們來模擬一下，upstream 上下游收發速度不一致對 Nginx 內存占用的影響。
模擬 Nginx 內存上漲
我這里模擬的是緩慢收包的客戶端，另外一邊是一個資源充沛的后端服務端，然后觀察 Nginx 的內存會不會有什么變化。
緩慢收包客戶端是用 golang 寫的，用 TCP 模擬 HTTP 請求發送，代碼如下所示。
- package main
- import (
- "bufio"
- "fmt"
- "net"
- "time"
- )
- func main() {
- conn, _ := net.Dial("tcp", "10.211.55.10:80")
- text := "GET /demo.mp4 HTTP/1.1rnHost: ya.test.mernrn"
- fmt.Fprintf(conn, text)
- for ; ; {
- _, _ = bufio.NewReader(conn).ReadByte()
- time.Sleep(time.Second * 3)
- println("read one byte")
- }
- }
在測試 Nginx 上開啟 pidstat 監控內存變化
- pidstat -p pid -r 1 1000
運行上面的 golang 代碼，Nginx worker 進程的內存變化如下所示。
04:12:13 是 golang 程序啟動的時間，可以看到在很短的時間內，Nginx 的內存占用就漲到了 464136 kB（接近 450M)，且會維持很長一段時間。
同時值得注意的是，proxy_buffers 的設置大小是針對單個連接而言的，如果有多個連接發過來，內存占用會繼續增長。下面是同時運行兩個 golang 進程對 Nginx 內存影響的結果。
可以看到兩個慢速客戶端連接上來的時候，內存已經漲到了 900 多 M。
解決方案
因為要支持上百萬的連接，針對單個連接的資源配額要小心又小心。一個最快改動方式是把 proxy_buffering 設置為 off，如下所示。
- proxy_buffering off;
經過實測，在壓測環境修改了這個值以后，以及調小了 proxy_buffer_size 的值以后，內存穩定在了 20G 左右，沒有再飆升過，內存占用截圖如下所示。
在測試環境重復剛才的測試，結果如下所示。
可以看到這次內存值增長了 64M 左右。為什么是增長 64M 呢？來看看 proxy_buffering 的 Nginx 文檔（nginx.org/en/docs/htt…
When buffering is enabled, nginx receives a response from the proxied server as soon as possible, saving it into the buffers set by the proxy_buffer_size and proxy_buffers directives. If the whole response does not fit into memory, a part of it can be saved to a temporary file on the disk. Writing to temporary files is controlled by the proxy_max_temp_file_size and proxy_temp_file_write_size directives.
When buffering is disabled, the response is passed to a client synchronously, immediately as it is received. nginx will not try to read the whole response from the proxied server. The maximum size of the data that nginx can receive from the server at a time is set by the proxy_buffer_size directive.
可以看到，當 proxy_buffering 處于 on 狀態時，Nginx 會盡可能多的將后端服務器返回的內容接收并存儲到自己的緩沖區中，這個緩沖區的最大大小是 proxy_buffer_size * proxy_buffers 的內存。
如果后端返回的消息很大，這些內存都放不下，會被放入到磁盤文件中。臨時文件由 proxy_max_temp_file_size 和 proxy_temp_file_write_size 這兩個指令決定的，這里不展開。
當 proxy_buffering 處于 off 狀態時，Nginx 不會盡可能的多的從代理 server 中讀數據，而是一次最多讀 proxy_buffer_size 大小的數據發送給客戶端。
Nginx 的 buffering 機制設計的初衷確實是為了解決收發兩端速度不一致問題的，沒有 buffering 的情況下，數據會直接從后端服務轉發到客戶端，如果客戶端的接收速度足夠快，buffering 完全可以關掉。但是這個初衷在海量連接的情況下，資源的消耗需要同時考慮進來，如果有人故意偽造比較慢的客戶端，可以使用很小的代價消耗服務器上很大的資源。
其實這是一個非阻塞編程中的典型問題，接收數據不會阻塞發送數據，發送數據不會阻塞接收數據。如果 Nginx 的兩端收發數據速度不對等，緩沖區設置得又過大，就會出問題了。
Nginx 源碼分析
讀取后端的響應寫入本地緩沖區的源碼在 src/event/ngx_event_pipe.c 中的 ngx_event_pipe_read_upstream 方法中。這個方法最終會調用 ngx_create_temp_buf 創建內存緩沖區。創建的次數和每次緩沖區的大小由 p->bufs.num（緩沖區個數） 和 p->bufs.size（每個緩沖區的大小）決定，這兩個值就是我們在配置文件中指定的 proxy_buffers 的參數值。這部分源碼如下所示。
- static ngx_int_t
- ngx_event_pipe_read_upstream(ngx_event_pipe_t *p)
- {
- for ( ;; ) {
- if (p->free_raw_bufs) {
- // ...
- } else if (p->allocated < p->bufs.num) { // p->allocated 目前已分配的緩沖區個數，p->bufs.num 緩沖區個數最大大小
- /* allocate a new buf if it's still allowed */
- b = ngx_create_temp_buf(p->pool, p->bufs.size); // 創建大小為 p->bufs.size 的緩沖區
- if (b == NULL) {
- return NGX_ABORT;
- }
- p->allocated++;
- }
- }
- }
Nginx 源碼調試的界面如下所示。
后記
還有過程中一些輔助的判斷方法，比如通過 strace、systemtap 工具跟蹤內存的分配、釋放過程，這里沒有展開，這些工具是分析黑盒程序的神器。
除此之外，在這次壓測過程中還發現了 worker_connections 參數設置不合理導致 Nginx 啟動完就占了 14G 內存等問題，這些問題在沒有海量連接的情況下是比較難發現的。
最后，底層原理是必備技能，調參是門藝術。上面說的內容可能都是錯的，看看排查思路就好。
