Nginx 學習筆記（四）之 內存占用過高分析

一、內存占用查看情況

 執行如下命令確定 nginx 主進程

#查看主進程

ps aux|grep nginx

# 查看主進程下所有子進程占用內存情況，以此來進行統計

ps --ppid <pid> U

 

(1) 查找主進程看

命令 ps aux|grep nginx

 

 從上圖可以看到 master process 有好幾個，這是因為本服務器安裝了多個nginx軟件的緣故，這里主要統計 進程為 88657 的 nginx.

(2) 統計 所有子進程 內存

命令：ps --ppid 88657 u |awk 'BEGIN{a=0;}{a+=$6}END{a=a/1024;print a}'

 

 命令 ps --ppid 88657 u 可以看到 88657 下所有子進程的內存情況

 

 通過 awk 對子進程 RSS（內存值）進行累加，從上圖中可以看到其實累加后 值為：2476572K，再轉換為 M為：2418.53M

(2) 統計內存

 命令 ps aux|grep 88657 查詢主進程內存占用情況

 可以看到占用內存為 14192K 

因此 nginx 占用內存為：所有 work process 內存和 + master process = 2476572K + 14192K = 2490764K ，轉換為 M單位為 ：2432.38M 

二、知識點

 查閱資料：

https://blog.csdn.net/sh2018/article/details/84025355
https://www.cnblogs.com/caicairui/p/8507472.html

了解到 nginx 內存占有情況 和 work_processes 及 work_connections 這兩個配置有關系，可以得到如下結論：

• work_connections 表示 並發支持的最大連接數，每個連接大概為 0.4K -0.5K 大小；
• work_processes 設置為 auto 時，其數量會隨着不同CPU核數自動調整，本案例中服務器有 128 核（cat /proc/cpuinfo | grep processor），因此 work_processes 有128個，每個 work_process 會占用一個 CPU處理請求
• 每個 work_process 支持最大並發數為 work_connections，這是在某個時候，nginx 將所有請求都交給一個 work_process 處理才會出現，不過很少出現該種情況
• nginx 內存大小計算方式為：work_connections*0.5K*work_processes + master process內存大小

三、解決方式

 調整 work_connections、work_processes 配置值，主要是參考 https://www.cnblogs.com/xwgli/p/12322791.html

# 設置 nginx 的工作進程數量（默認值：1）
# 最大為CPU的邏輯處理器數量，比如6核心12線程的CPU，最大設置就是12，如果是6核心6線程，則為6。
# 需要考慮系統資源分配，每多一個運行進程，內存占用都要多一份（比如一個進程為400M，兩個就是400M*2=800M）
worker_processes  1;

# 設置 nginx 最大文件描述符打開限制
# 在 Linux 系統中，每建立一個連接都是打開一個文件描述符（作為反向代理或負載均衡連接數量會翻倍，因為內外各一個）
# 所以文件的打開限制決定了 nginx 的最大連接數（應大於 worker_processes * worker_connections）
# 此處配置需要參考系統的限制（ulimit -n），不能超過系統的最大限制
worker_rlimit_nofile 65535;

events {

    # 此為 Linux 系統特為處理大批量文件描述符而作改進的 poll 事件模型
    use epoll;
    
    # 設置每個工作進程可處理的最大連接數量
    # 此設置將直接影響工作進程的內存固定占用，每個連接大概占用內存 0.4~0.5KB 左右
    # 此值應小於 worker_connections / worker_processes
    worker_connections 65535;
    
    # 允許同時接受多個網絡連接
    multi_accept on;
}

http {
    # 配置文件類型映射，以及默認的 mime 類型
    include       mime.types;
    default_type  application/octet-stream;
    
    # 設置請求頭緩沖區大小，超過后會使用下面的配置大小
    # client_header_buffer_size 1K
    # 設置更大的請求頭緩沖區大小，如果請求頭超出可能會返回 HTTP 414
    # large_client_header_buffers 8K
    
    # 設置請求體緩沖區大小，大於此緩沖區大小的，將寫入磁盤文件
    # client_body_buffer_size 16K
    # 設置請求體最大大小（此項影響上傳文件的最大大小）
    client_max_body_size 1000m;

    # 提供了一種減少拷貝次數，提升文件傳輸性能的方法。（靜態文件由內核直接發送給 socket，而不是由進程讀取到內存再發送）
    sendfile        on;
    
    # 降低數據包發送頻率，當數據包滿時再發送，減少網絡數據包數量，降低網絡擁塞情況，僅在 sendfile on 時生效
    tcp_nopush     on;
    
    # 為 http 請求保持 tcp 連接，避免短時間內多次 http 請求反復三次握手來建立 tcp 連接
    # 配置保持連接的數量（默認值：100）
    keepalive_requests 100;
    # 配置保持連接的時長
    keepalive_timeout  10;

    gzip on;                        # 開啟 gzip，會增加對 cpu 的資源消耗
    gzip_min_length 1k;                # 低於 1kb 的資源不壓縮
    gzip_comp_level 2;                # 壓縮級別 1-9，越大壓縮率越高，同時消耗 cpu 資源也越多。
    # 需要壓縮哪些響應類型的資源，多個空格隔開。有些格式的文件壓縮效率較低，不建議壓縮。
    gzip_types text/plain application/json application/javascript application/x-javascript text/javascript text/xml text/css;
    gzip_disable "MSIE [1-6]\.";    # 配置禁用 gzip 條件，支持正則。此處表示 ie6 及以下不啟用 gzip（因為 ie 低版本不支持）
    gzip_vary on;                    # 配置添加 Vary 響應頭
    
    # 暫不知道用途，主要用來解決：could not build the proxy_headers_hash 錯誤
    proxy_headers_hash_max_size 51200;
    proxy_headers_hash_bucket_size 6400;

    server {
        listen       80;
        
        server_name  demo.psy-cloud.com;

        location * {
            return 404;
        }
    }
}