什么是殺死我的PHP進程，並留下如此多的睡眠mysql連接？

Question

我在調查許多睡眠MySQL連接的問題時遇到了麻煩。

每隔一兩天我會注意到所有（151）MySQL連接都已被占用，並且所有這些連接似乎都在睡覺。

我對此進行了調查，其中一個最合理的解釋是PHP腳本剛剛被殺死，后面留下了一個MySQL連接。 我們在請求開始時記錄訪問，並在請求完成時更新該日志，因此我們可以確定某些請求確實已啟動，但未完成，這表明該腳本確實以某種方式被殺死。

現在，令人擔憂的是， 這只發生在1個特定用戶 ，而且只發生在1個特定頁面上。 該頁面適用於其他所有人，當我在生產環境中以此用戶身份登錄並執行完全相同的操作時，一切正常。

現在，我有兩個問題：

1. 我想找出PHP腳本被殺的原因 。 這可能與客戶有什么關系嗎？ 客戶端可以做“某事”來結束請求並殺死php腳本嗎？ 如果是這樣，為什么我在Apache日志中看不到任何證據？ 或許我不知道該找什么？ 我如何確定腳本是否確實被殺死或者是什么原因造成的？

2. 我該如何防止這種情況？ 我可以以某種方式設置每個PHP會話的mysql連接數限制？ 或者我可以以某種方式檢測長時間運行和睡眠的mysql連接並殺死它們？ 我不能選擇將連接超時設置為更短的時間，因為有些進程運行時間要長得多，並且151個連接在不到2分鍾的時間內就用完了。 增加連接數也無法解決問題。 所以，基本上..我如何殺死睡眠時間超過1分鍾的進程？

最好的解決方案是我找出為什么1個用戶的請求可以占用所有數據庫連接並基本上關閉整個應用程序。 以及如何防止這種情況。

任何幫助非常感謝。

Answer 1

您可以減少MySQL服務器的wait_timeout變量 。 這指定MySQL在中止連接之前等待非交互式連接上的任何內容的秒數。 默認值為28800秒，看起來相當高。 您可以通過執行SET GLOBAL wait_timeout = X;來動態設置它SET GLOBAL wait_timeout = X; 一旦。

您仍然可以再次為cronjobs增加它。 只需執行查詢SET SESSION wait_timeout = 28800; 在cronjob的開頭。 這只會影響當前連接。

請注意，如果將此設置得太低，這可能會導致問題 。 雖然我沒有看到那么多問題。 大多數腳本應該在不到一秒鍾內完成。 因此設置wait_timeout=5應該不會造成傷害......