Apache這幾天失控，導致MySQL崩潰兩次。這一切都是從我遷移一個 WordPress 網站開始的，該網站還包含一個 phpBB 論壇。
我在伺服器管理方面經驗不是很豐富，因此我很難找出導致問題的原因。當我注意到 MySQL 宕機時，我運行 TOP 並看到系統負載飆升至 98.00。伺服器運行 10 個 V-HOST，所有這些都接收大量流量，因此我顯然看到許多 apache-2 進程正在運行。
伺服器高負載持續了10分鐘，然後恢復正常狀態。此時我沒有看到網路流量激增。
不幸的是，MySQL 錯誤日誌記錄已停用（現已重新啟用），因此沒有任何線索。但我很確定這是因為 Apache 消耗了所有資源，因此 MySQL 進程 ID 被殺死。
我的問題是：
下次發生這種情況時 - 我如何確定導致系統負載峰值的原因？難道是php腳本發瘋了？會不會是DDOS攻擊？
有沒有辦法在MySQL崩潰時自動重新啟動？
我現在已經安裝了htop。這會比 更有用嗎top？
這是我的伺服器統計：
m1.xlarge (8 ECUs, 4 vCPUs, 15 GiB memory, 4 x 420 GiB Storage Capacity)
Ubuntu Server 12.04.3 LTS
答案1
MySQL 可能仍然沒有記錄任何內容，因為可能發生的情況是，由於 apache 子進程的系統記憶體壓力，它被系統毫不客氣地殺死。 /var/log/syslog 中應該有這樣的痕跡。
MySQL 應該嘗試在崩潰或強制終止時重新啟動，但除非有足夠的記憶體可用，否則它不能這樣做......並且mysqld_safe 不會將第二次失敗視為“崩潰”，而是將其視為“拒絕開始”，所以它不會繼續嘗試。失敗的重啟嘗試經常被管理員誤解為“崩潰”，因為原始故障的本質隱藏在 MySQL 錯誤日誌中一條容易被忽視的消息後面：
mysqld_safe Number of processes running now: 0
看InnoDB 崩潰事後分析我懷疑情況與您的情況類似。
「為什麼」的看似簡單的答案是，在Apache 和MySQL 之間，您所擁有的負載以及當前的配置，您的電腦上沒有足夠的內存，並且存在一些與流量負載相關的臨界點，導致了這種情況的出現。
Apache 為來自子進程的每個並發瀏覽器請求提供服務，因此並發連線數增加時，子進程的數量也會增加。您首先需要在 apache 配置中限制此值，以便您可以了解實際導致並發連接增加的原因......這只是一個沉重但合法的流量峰值嗎？某種拒絕服務？由於運行時間太長而延遲請求的資料庫查詢？有什麼需要優化的嗎？
http://httpd.apache.org/docs/2.2/mod/mpm_common.html#maxclients
限制並發 Apache 進程應該有助於防止這種情況，但要明確的是，認為這是完整的解決方案是天真的，所以我不想暗示這一點。一旦流程限制在合理或至少安全的水平，您就可以繼續確定到底發生了什麼。 （Apache 還有其他限制控制，但這不是我的專業領域。）
「最佳實踐」當然是在不同的硬體上運行資料庫，這樣應用程式就無法殺死它。雖然從表面上看，透過共享一台機器來「最大限度地利用」它似乎更有效，但這是一種錯誤的經濟。在典型的工作負載中，MySQL 使用的大部分記憶體是在啟動時分配的，並在 MySQL 伺服器運行期間一直保留。對 CPU 的需求可能會共用 MySQL 和 Apache 的尖峰時間，因為它們最終服務於相同的負載。實際上，使用兩台m1.large 機器而不是一台m1.xlarge 可能會更好，而且成本是相同的，因為較小的機器恰好是較大機器價格的一半......即使您已經提前付款如需額外折扣，這個改變是可以完成的。
答案2
您需要檢查以下幾點：
-檢查/var/log/messages：如果沒有更多記憶體可用，oomkiller 可以殺死 mysql 進程。使用 free -lm 檢查記憶體（無快取）
-如果您將 apache 與 prefork mpm 一起使用：檢查進程數。如果 apache 透過連結到 mysql 堆疊大量進程（在繁重的工作負載期間），則延遲和使用的記憶體會快速增加。
-使用a檢查mysql啟動的線程數顯示全域狀態：threads_cached、threads_created 和threads_running 很重要，需要檢查（threads_created 應接近0）。
-檢查Mysql使用的ram。
答案3
您也可以考慮實施中央處理器組並為mysql預留資源。這是最接近在不同硬體上運行這些服務的方式，但仍為您提供維護單一伺服器的好處。