時々、Linux LAMP サーバー (PHP-FPM、HW RAID 上のシン LVM 上の XFS、Centos8 を使用) がアクセス不能になり、HTTP(S) 要求に応答しなくなります。
集中ログにより、このような場合、負荷平均がすぐに数百に跳ね上がり、プロセス (systemd-journald、php プロセス、カーネル xfs/dm スレッドなど) が D 状態になることがわかりました。iostat と pidstat によると、負荷平均が 170 前後で推移している間、CPU とディスクにはほとんど負荷がかかっていません。これは非常に奇妙です。htop/ps の出力からは、この動作を説明するような不正なプロセスは 1 つもグループもありません。何らかの「障害」に遭遇しているように見えるのは、単に標準プロセスだけです。
ディスク監視に関するその他の奇妙な点は、これらの過負荷イベント中に、iostat がパーティション /var の w_await を断続的にかなり高く報告することです (2500 ～ 5000 ミリ秒ですが、/var/log、/var/lib/mysql などの他のパーティションでは、ほとんどの場合 10 ミリ秒を超えません)。このパーティションはほとんどの場合静かであるはずなので、iostat がなぜそこでこれほど大きな w_await 時間を報告するのかは明らかではありません。
唯一の解決策は、サーバーの電源を入れ直すことです。
これは同じ種類の 2 つのサーバーで発生しますが、他のサーバーでは発生しません。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
いくつかのクエリを高速化すると、負荷平均と I/O が減少し、ボトルネックが緩和される可能性があります。