我們遇到了問題，我們的rackspace WordPress 伺服器在發送電子郵件後因中等流量而崩潰。
伺服器規格為：
CPU 2 vCPUs
RAM 2 GB
System Disk 80 GB
Network 240 Mb / s
Disk I/O Good
跑步：
Centos 7.0
Wordpress 4.3.1
Httpd 2.4.6
PHP 5.4.11
MariaDB 5.5.41
據我所知，安裝相當標準，資料庫也相當標準，有索引，而且相當小。我們也是wordpress物件快取。
根據新遺跡；在正常流量期間，該網站大約 80% 的時間花在 PHP 上，15% 的時間花在 Web 外部上，只有一小部分時間花在資料庫上。平均標準頁面應用程式時間約為 800 毫秒，這對我來說確實很慢。
在 1 分鐘內執行 250 個連線的負載測試會導致連線時間逐漸變長，然後在大約 30 個連線後開始逾時，伺服器變得無回應（即使流量再次下降）。它需要硬重啟才能再次啟動。
我無法使用 putty 進行連接，並且主頁在超時和返回可怕的“建立資料庫連接時出錯”之間搖擺。
在最近的測試中使用機架空間監控代理，CPU 似乎在死亡前達到了 100% 的峰值，使用的記憶體峰值約為 1.6GB，空閒下降到約 100MB。看起來也使用了大約 2GB 的交換記憶體（總共 4GB）。標準使用率似乎約為 15% CPU、800MB 記憶體和 400MB 交換空間。
我們的 Apache 配置沒有設定以下任何內容（/etcdo 中沒有文件）；超時、KeepAlive、MaxKeepAliveRequests、KeepAliveTimeout；所以我猜測它正在使用預設值。
我查看了 mariadb 設定：
innodb_buffer_pool_size = 1400M
max_user_connections = 0
這似乎不是原因。
我也打開了 Performance_schema，但我真的不知道我在尋找什麼。我什至不確定資料庫是問題所在。
我很想升級實例，但我寧願更清楚地了解瓶頸在哪裡以及導致伺服器死機的原因，而不僅僅是減慢速度。
關於從哪裡開始有什麼想法嗎？似乎有很多可能的調整和很多資訊。
答案1
在任何類型的事件期間密切監控都是至關重要的。正如我們所見，真相大白了：
在最近的測試中使用機架空間監控代理，CPU 似乎在死亡前達到了 100% 的峰值，使用的記憶體峰值約為 1.6GB，空閒下降到約 100MB。看起來也使用了大約 2GB 的交換記憶體（總共 4GB）。標準使用率似乎約為 15% CPU、800MB 記憶體和 400MB 交換空間。
眾所周知，PHP 是 CPU 密集型的。您已經使用了所有可用的 CPU 和幾乎所有可用的 RAM。
您應該先採取措施來處理這個問題，例如操作碼快取（例如 Zend OPcache）和檔案快取（例如 W3 Total Cache WordPress 外掛程式）。如果這些沒有幫助足夠的，那麼就該升級實例了。
答案2
您可能只是同時運行太多進程，內存不足，並且攪動交換。可能是其他事情被鎖定了，但首先處理這個問題，然後看看你處於什麼位置。
您還沒有告訴我們您使用的是 mod_php 還是 php-fpm 之類的東西。後者可以更好地處理負載，但無論哪種情況，請確保運行的 php 進程數不會超過記憶體容量。運行超過 5 或 10 個進程可能不會獲得任何效能優勢，但 mod_php 的預設運行尤其會超出您的記憶體容量。此外，每 30 個左右的請求就會進行回收處理。如果您為資料庫和作業系統提供 1GB，那麼您的其他 GB 可能無法處理 10 個 WordPress 進程。看看他們佔用了多少記憶體併計算出來，並留有一點間隙。在正常情況下，您不應該使用任何交換。
查看您的保持活動設定。對於 Apache，您可能最好將其關閉或將其設定為 1 秒。 Nginx 更好地處理保持活動狀態。事實上，這是 nginx 在像 WordPress 這樣的 php 應用程式中表現更好的唯一真正重要的原因（儘管它是以不太令人愉快的配置為代價的）。這很可能不是您的測試的一個因素，但對於真正的瀏覽器來說很重要。
100% CPU 令我驚訝。使用 top 看看是什麼在使用它。另請記住，100% 通常意味著一個核心 100%。您可能只是看到一個 cron 作業啟動，對於 WordPress，該作業通常不是「cron」本身，而是在處理 Web 請求時作為額外運行的作業。缺乏操作碼快取也可能導致 CPU 使用率過高。