nginx worker 進程頻繁重啟通常由內存泄漏引起，需通過系統方法排查。1. 確認內存泄漏：監控內存占用是否持續增長；2. 開啟調試日志：設置 error_log 為 debug 級別獲取詳細信息；3. 使用 top、htop 或 valgrind 監控內存使用；4. 檢查 nginx 模塊：逐個禁用模塊定位問題源；5. 審查代碼：檢查內存分配釋放匹配、循環引用及未釋放資源；6. 使用 gdb 調試：連接進程分析內存變化；7. 檢查 lua 腳本：確保資源正確釋放；8. 升級或降級 nginx 版本：修復已知 bug；9. 預防措施包括選擇可靠模塊、編寫高質量腳本、定期更新和合理配置；10. 可使用 supervisor 或 systemd 設置自動重啟緩解服務中斷；11. 使用 valgrind 分析泄漏時需開啟完整檢測模式并模擬請求，結合日志輸出精準定位問題。整個過程應結合工具與代碼審查，最終解決內存泄漏并優化性能。
Nginx worker 進程頻繁重啟通常指向一個嚴重的問題，而內存泄漏是其中一個常見的原因。排查這類問題需要耐心和系統的方法，從日志分析到代碼審查，每一步都至關重要。
首先需要確認是否真的是內存泄漏。觀察一段時間內 Nginx worker 進程的內存占用情況，如果持續增長且沒有下降的趨勢，基本可以確定存在內存泄漏。
解決方案
-
開啟 Nginx 的調試日志： 修改 Nginx 配置文件，將 error_log 指令的級別設置為 debug。這樣可以獲得更詳細的日志信息，幫助定位問題。注意，調試日志會產生大量數據，只在排查問題時開啟，問題解決后及時關閉。
error_log /var/log/nginx/error.log debug;
-
使用工具監控內存： 可以使用 top、htop 或 valgrind 等工具監控 Nginx worker 進程的內存使用情況。top 和 htop 可以實時查看進程的內存占用，而 valgrind 則可以更深入地分析內存泄漏的具體位置。
- top：在終端輸入 top 命令，然后按下 Shift + m，可以按內存占用排序。
- htop：一個更友好的 top 替代品，需要單獨安裝。
- valgrind –leak-check=full nginx -g “daemon off;”： 這是一個強大的內存調試工具，但會顯著降低 Nginx 的性能，只在測試環境中使用。
-
檢查 Nginx 模塊： 內存泄漏很可能發生在 Nginx 的第三方模塊中。逐個禁用模塊，觀察內存占用情況，可以快速定位問題模塊。
- 修改 Nginx 配置文件，注釋掉 load_module 指令，禁用模塊。
- 重啟 Nginx，觀察內存占用情況。
-
代碼審查： 如果確定是某個模塊導致的內存泄漏，就需要審查該模塊的代碼。重點關注以下幾個方面：
- 內存分配和釋放是否匹配。
- 是否存在循環引用。
- 是否有未釋放的資源。
可以使用靜態代碼分析工具，例如 cppcheck，來輔助代碼審查。
-
使用 GDB 調試： 如果代碼審查無法定位問題，可以使用 GDB 調試 Nginx worker 進程。GDB 允許你單步執行代碼，查看變量的值，以及分析內存的使用情況。
- 首先，需要安裝 Nginx 的調試符號。
- 然后，使用 GDB 連接到 Nginx worker 進程： gdb -p
。 - 設置斷點，逐步執行代碼，觀察內存的變化。
-
檢查 Lua 腳本 (如果使用): 如果使用了 ngx_lua 模塊，內存泄漏可能發生在 Lua 腳本中。檢查 Lua 代碼中是否有未釋放的資源，例如未關閉的文件句柄或未釋放的表。
-
Nginx 版本升級或降級： 某些 Nginx 版本可能存在已知的內存泄漏問題。嘗試升級到最新版本或降級到穩定版本，看看是否能解決問題。
Nginx 內存泄漏排查思路：如何快速定位問題？
快速定位 Nginx 內存泄漏問題，關鍵在于縮小排查范圍。首先，通過監控工具確認是否真的存在內存泄漏，并記錄內存增長的速度。然后，根據日志信息和模塊的使用情況，初步判斷可能存在問題的模塊。接下來，逐個禁用模塊，觀察內存占用情況，進一步縮小范圍。最后，使用代碼審查和 GDB 調試等工具，深入分析問題模塊的代碼，找到內存泄漏的具體位置。
Nginx 內存泄漏的常見原因有哪些？
Nginx 內存泄漏的常見原因包括：
- 第三方模塊的 Bug： 這是最常見的原因之一。第三方模塊的代碼質量參差不齊，很容易出現內存泄漏。
- Lua 腳本的問題： 如果使用了 ngx_lua 模塊，Lua 腳本中的錯誤也可能導致內存泄漏。
- Nginx 本身的 Bug： 盡管 Nginx 的代碼質量很高，但仍然可能存在 Bug，導致內存泄漏。
- 配置錯誤： 某些配置錯誤也可能導致內存泄漏，例如緩存配置不合理。
- 操作系統的問題： 在極少數情況下，操作系統的問題也可能導致 Nginx 內存泄漏。
如何預防 Nginx 內存泄漏？
預防 Nginx 內存泄漏，需要從多個方面入手：
- 選擇可靠的第三方模塊： 在選擇第三方模塊時，要選擇經過充分測試和驗證的模塊，避免使用來路不明的模塊。
- 編寫高質量的 Lua 腳本： 如果使用了 ngx_lua 模塊，要編寫高質量的 Lua 腳本，避免出現內存泄漏。
- 定期更新 Nginx： 定期更新 Nginx 到最新版本，可以修復已知的 Bug，提高系統的穩定性。
- 合理的配置： 合理配置 Nginx 的各項參數，避免出現配置錯誤。
- 定期監控： 定期監控 Nginx 的內存使用情況，及時發現并解決問題。
Nginx 內存泄漏，CPU 占用率高，如何解決？
Nginx 內存泄漏和 CPU 占用率高通常是相互關聯的。內存泄漏會導致 Nginx 不斷分配和釋放內存，增加 CPU 的負擔。解決這個問題，需要先定位并解決內存泄漏，然后才能降低 CPU 占用率。
解決內存泄漏的方法前面已經介紹過了，這里重點介紹如何降低 CPU 占用率。
- 優化 Nginx 配置： 優化 Nginx 的配置，例如調整 worker 進程的數量，啟用 Gzip 壓縮，使用緩存等，可以有效降低 CPU 占用率。
- 使用緩存： 使用 Nginx 的緩存功能，可以將靜態資源和動態內容緩存起來，減少對后端服務器的請求，從而降低 CPU 占用率。
- 升級硬件： 如果 Nginx 服務器的硬件配置較低，可以考慮升級硬件，例如增加內存和 CPU 核心數。
- 代碼優化： 如果使用了第三方模塊或 Lua 腳本，可以對代碼進行優化，提高代碼的執行效率，從而降低 CPU 占用率。
Nginx 內存泄漏導致頻繁重啟，如何設置自動重啟？
雖然解決內存泄漏才是根本之道，但在問題解決之前，設置自動重啟可以緩解服務中斷的影響?？梢允褂?Supervisor 或 Systemd 等工具來監控 Nginx worker 進程，并在進程崩潰時自動重啟。
-
Supervisor： Supervisor 是一個進程管理工具，可以監控和管理 linux 系統上的進程。
-
安裝 Supervisor： apt-get install supervisor (debian/ubuntu) 或 yum install supervisor (centos/RHEL)。
-
創建 Nginx 的 Supervisor 配置文件： /etc/supervisor/conf.d/nginx.conf。
[program:nginx] command=/usr/sbin/nginx -g "daemon off;" autostart=true autorestart=true user=root redirect_stderr=true stdout_logfile=/var/log/nginx/supervisor.log
-
更新 Supervisor 配置： supervisorctl update。
-
啟動 Supervisor： supervisorctl start nginx。
-
-
Systemd： Systemd 是 Linux 系統的初始化系統和服務管理器。
-
創建 Nginx 的 Systemd 配置文件： /etc/systemd/system/nginx.service。
[Unit] Description=The Nginx HTTP and reverse proxy server After=network.target remote-fs.target nss-lookup.target [Service] Type=forking PIDFile=/run/nginx.pid ExecStart=/usr/sbin/nginx -g "daemon off;" ExecReload=/bin/kill -s HUP $MaiNPID KillMode=process Restart=on-failure [Install] WantedBy=multi-user.target
-
啟用 Systemd 服務： systemctl enable nginx.service。
-
啟動 Systemd 服務： systemctl start nginx.service。
-
如何使用 Valgrind 分析 Nginx 內存泄漏？
Valgrind 是一個強大的內存調試工具，可以檢測內存泄漏、非法內存訪問等問題。使用 Valgrind 分析 Nginx 內存泄漏，需要以下步驟：
-
安裝 Valgrind： apt-get install valgrind (Debian/Ubuntu) 或 yum install valgrind (CentOS/RHEL)。
-
運行 Nginx with Valgrind： 使用 Valgrind 運行 Nginx，并開啟內存泄漏檢測：
valgrind --leak-check=full --show-leak-kinds=all --track-origins=yes nginx -g "daemon off;"
- –leak-check=full： 開啟完整的內存泄漏檢測。
- –show-leak-kinds=all： 顯示所有類型的內存泄漏。
- –track-origins=yes： 跟蹤未初始化值的來源。
- nginx -g “daemon off;”： 以非守護進程模式運行 Nginx，方便 Valgrind 監控。
-
模擬請求： 使用 cURL 或其他工具模擬請求，觸發 Nginx 的內存分配和釋放操作。
-
分析 Valgrind 輸出： Valgrind 會輸出詳細的內存泄漏報告，包括泄漏的內存大小、泄漏的位置、泄漏的類型等。根據報告，可以定位到具體的代碼行，從而解決內存泄漏問題。
Valgrind 的輸出可能非常冗長，可以使用 –log-file 選項將輸出保存到文件中，方便分析。
valgrind --leak-check=full --show-leak-kinds=all --track-origins=yes --log-file=valgrind.log nginx -g "daemon off;"
-
注意事項：
- 使用 Valgrind 會顯著降低 Nginx 的性能，只在測試環境中使用。
- Valgrind 的輸出可能包含大量的噪聲，需要仔細分析才能找到真正的內存泄漏。
- Valgrind 需要 Nginx 的調試符號才能提供更詳細的錯誤信息。
總結
Nginx worker 進程頻繁重啟的內存泄漏排查是一個復雜的過程，需要耐心和細致的分析。從日志分析到代碼審查，每一步都至關重要。使用合適的工具，例如 top、htop、valgrind 和 GDB，可以幫助你快速定位問題。記住，預防勝于治療，選擇可靠的第三方模塊，編寫高質量的代碼，定期更新 Nginx，可以有效預防內存泄漏的發生。
