Apache MPM 工作人員陷入 G(優雅地完成)成長 - “記分牌已滿”

Apache MPM 工作人員陷入 G(優雅地完成)成長 - “記分牌已滿”

運行 MPM 工作程序、Apache 2.4.46、Debian 9

優雅的整理工人會隨著時間的推移而成長,他們似乎永遠不會完成。最終我耗盡了容量並收到“記分板已滿”錯誤。如果我重新啟動 apache,它們就會被釋放。

我不相信它與我的網站程式碼(php)有任何關係,因為許多掛起的請求只是純粹的圖像 GET,不涉及 php。

在此輸入影像描述

<IfModule mpm_worker_module>
ServerLimit 500
StartServers       10
MinSpareThreads    50
MaxSpareThreads    100
    ThreadLimit          64
    ThreadsPerChild      64
    MaxRequestWorkers     500
    MaxConnectionsPerChild   0
</IfModule>

記分牌 在此輸入影像描述

範例 g 工人 在此輸入影像描述

apache 一週以來,免費插槽不斷減少 在此輸入影像描述

在此輸入影像描述

嘗試開啟和關閉保持活動狀態

在此輸入影像描述

答案1

當您使用 MPM 工作執行緒時,請求由進程中存在的執行緒處理。

https://httpd.apache.org/docs/2.4/mod/worker.html

單一控制進程(父進程)負責啟動子進程。每個子程序都會建立 ThreadsPerChild 指令中指定的固定數量的伺服器線程,以及一個偵聽器線程,該偵聽器線程偵聽連接並在連接到達時將它們傳遞給伺服器執行緒進行處理。

在 Linux 上,一個進程「包含」線程,即一個 PID 可以有多個線程,這些線程與該 PID 中的其他線程共享記憶體(以及其他資源)。

事實上,Linux實際上只關心“任務”,一個非多執行緒進程是一個帶有容器的PID任務。

當您優雅地重新載入 Apache 時,您就終止了包含該進程的進程。這裡發生的情況是 Apache 讓每個執行緒等待,直到包含進程中的所有執行緒都完成後才重新啟動容器 PID。

因此,在您的情況下,該列表中的所有進程中都包含一個線程,該線程仍然忙碌或以某種方式卡住。

你有幾個選擇。

  1. 無論如何放棄等待並重新啟動。
  2. 找到問題線程(可能是應用程式中的錯誤)並修復它。

1、很容易。增加GracefulShutdownTimeout一個值很高但不愚蠢的配置選項。說900秒。預設情況下,這是無限的,這意味著您的線程永遠等待問題線程完成。

這樣做的主要缺點是,您有可能在執行關鍵操作時遇到某個進程,而該進程的終止可能會損壞檔案或微妙地破壞應用程式。您還有可能在處理過程中終止客戶端(非常小)。

2,將涉及您發現卡在工作人員列表中的線程,然後診斷連接正在做什麼,但您一定會發現什麼可能是設計缺陷,並且您可以在崩潰之前更自信地解釋該行為消除有問題的線程。

相關內容