每隔一段時間，我們的 Linux LAMP 伺服器（在 HW RAID、Centos8 上的瘦 LVM 上使用 PHP-FPM、XFS）就會變得無法存取並停止回應 HTTP(S) 請求。
透過集中式日誌記錄，我們發現在這些情況下，平均負載迅速飆升至數百個，而越來越多的進程（systemd-journald、php 進程、核心 xfs/dm 執行緒...）進入 D 狀態。根據iostat和pidstat，CPU和磁碟的負載根本不高，而平均負載徘徊在170左右，這很奇怪。從 htop/ps 輸出來看，沒有單一或一組惡意進程可以解釋這種行為。這只是標準流程似乎遇到了某種「障礙」。
磁碟監控唯一奇怪的事情是，在這些過載事件期間，iostat 間歇性地報告分區/var 的w_await 相當高（2500-5000 毫秒，而其他分區如/var/log、/var/lib/mysql 大多無法克服） 10 毫秒）。該分區大部分時間應該是安靜的，因此不清楚為什麼 iostat 會報告如此大的 w_await 時間。
唯一的解決方案是重新啟動伺服器。
這種情況發生在兩台同類伺服器上，而不會發生在其他伺服器上。這似乎是某種 FS/區塊層/控制器/磁碟故障；許多進程突然開始等待磁碟或核心中的其他內容，但根據 iotop/iostat，磁碟沒有做太多事情。
有沒有辦法查詢 Linux 核心 FS/區塊層/控制器驅動程式它們到底在使用儲存做什麼以及代表哪個進程？像 iotop/iostat 這樣的標準工具只能告訴我 I/O 活動進程和磁碟分割活動的名稱，但不能告訴我哪些進程訪問哪個磁碟分割區以及它們到底在做什麼。
答案1
在這種情況下，我發現它有助於限制堆疊高層的連接數量。
當超過 100 時積極的進程正在運行，它們互相絆倒。他們正在爭奪資源（CPU 等）。最終效果是全部進程運行速度變慢，有時甚至讓您覺得唯一的解決方案就是重新啟動伺服器。
對於 MariaDB，我建議打開慢日誌，以便您可以識別對系統影響最大的查詢。然後加快速度。如果您需要協助，請提供查詢、其解釋和建立表格。更多的： http://mysql.rjweb.org/doc.php/mysql_analysis#slow_queries_and_slowlog
加快一些查詢的速度可能會減少 170 的平均負載和 I/O，從而緩解瓶頸。