一次百萬長鏈接壓測 Nginx OOM 的問題排查分析

時間  2020-09-29 標籤 一次 百萬 1000000 長 鏈接 壓 測 nginx oom 問題 排查 分析

在最近的一次百萬長鏈接壓測中，32C 128G 的四臺 Nginx 頻繁出現 OOM，出現問題時的內存監控以下所示。html

 

image.png

 

排查的過程記錄以下。java

現象描述

這是一個 websocket 百萬長鏈接收發消息的壓測環境，客戶端 jmeter 用了上百臺機器，通過四臺 Nginx 到後端服務，簡化後的部署結構以下圖所示。nginx

 

image.png

 

在維持百萬鏈接不發數據時，一切正常，Nginx 內存穩定。在開始大量收發數據時，Nginx 內存開始以每秒上百 M 的內存增加，直到佔用內存接近 128G，woker 進程開始頻繁 OOM 被系統殺掉。32 個 worker 進程每一個都佔用接近 4G 的內存。dmesg -T 的輸出以下所示。golang

[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 進程重啓後，大量長鏈接斷連，壓測就無法繼續增長數據量。web

排查過程分析

拿到這個問題，首先查看了 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 客戶端抓包偶爾能夠看到較多零窗口，以下所示。後端

 

image.png

 

到了這裏有了一些基本的方向，首先懷疑的就是 jmeter 客戶端處理能力有限，有較多消息堆積在中轉的 Nginx 這裏。緩存

爲了驗證想法，想辦法 dump 一下 nginx 的內存看看。由於在後期內存佔用較高的情況下，dump 內存很容易失敗，這裏在內存剛開始上漲沒多久的時候開始 dump。服務器

首先使用 pmap 查看其中任意一個 worker 進程的內存分佈，這裏是 4199，使用 pmap 命令的輸出以下所示。websocket

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 文件的可讀字符串內容，能夠看到是大量的請求和響應內容。

 

image.png

 

這樣堅決了是由於緩存了大量的消息致使的內存上漲。隨後看了一下 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 的內存會不會有什麼變化。

 

image.png

 

緩慢收包客戶端是用 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.1\r\nHost: ya.test.me\r\n\r\n"

    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 進程的內存變化以下所示。

 

image.png

 

04:12:13 是 golang 程序啓動的時間，能夠看到在很短的時間內，Nginx 的內存佔用就漲到了 464136 kB（接近 450M)，且會維持很長一段時間。

同時值得注意的是，proxy_buffers 的設置大小是針對單個鏈接而言的，若是有多個鏈接發過來，內存佔用會繼續增加。下面是同時運行兩個 golang 進程對 Nginx 內存影響的結果。

 

image.png

 

能夠看到兩個慢速客戶端鏈接上來的時候，內存已經漲到了 900 多 M。

解決方案

由於要支持上百萬的鏈接，針對單個鏈接的資源配額要當心又當心。一個最快改動方式是把 proxy_buffering 設置爲 off，以下所示。

proxy_buffering off;

通過實測，在壓測環境修改了這個值之後，以及調小了 proxy_buffer_size 的值之後，內存穩定在了 20G 左右，沒有再飆升過。後面能夠開啓 proxy_buffering，調整 proxy_buffers 的大小能夠在內存消耗和性能方面取得更好的平衡。

重複剛纔的測試，結果以下所示。

 

image.png

 

能夠看到此次內存值增加了 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 源碼調試的界面以下所示。

 

image.png

 

後記

還有過程當中一些輔助的判斷方法，好比經過 strace、systemtap 工具跟蹤內存的分配、釋放過程，這裏沒有展開，這些工具是分析黑盒程序的神器。

除此以外，在此次壓測過程當中還發現了 worker_connections 參數設置不合理致使 Nginx 啓動完就佔了 14G 內存等問題，這些問題在沒有海量鏈接的狀況下是比較難發現的。

最後，底層原理是必備技能，調參是門藝術。上面說的內容可能都是錯的，看看排查思路就好。

看完三件事❤️

若是你以爲這篇內容對你還蠻有幫助，我想邀請你幫我三個小忙：

  1. 點贊，轉發，有大家的 『點贊和評論』，纔是我創造的動力。

  2. 關注公衆號 『 java爛豬皮 』，不按期分享原創知識。

  3. 同時能夠期待後續文章ing🚀

 

 

做者：挖坑的張師傅

出處：club.perfma.com/article/433…

联系我们 沪ICP备2021010478号-7