推測だけで対策を進めると見当違いになるため、 実際に再現できるかを確認した手順と観測結果を残しておきます。
この記事では、同等構成の検証環境で実施した再現試験の内容を整理します。
実施メモ
プロダクション環境では検証できないため、 対象サーバーを複製した検証環境を用意しました。
負荷生成には h2load を利用し、
HTTP/2 接続数を段階的に増やして変化を観測します。
h2load(1) — nghttp2 1.69.0-DEV documentation
https://nghttp2.org/documentation/h2load.1.html
検証環境
- 検証開始時インスタンス:
t2.micro（1 vCPU / 1 GiB RAM） - 構成: Apache + PHP-FPM + MySQL
- 観測対象: Apache ログ、PHP-FPM ログ、
topのリソース状態
事象の再現結果
負荷を徐々に増加させたところ、 本番で発生したものと近い「SSH 接続不能を伴うハングアップ状態」を再現できました。
観測結果は次の通りです。
- SSH ログイン不能
- AWS コンソールからの停止操作に時間を要する
- 再起動後、Apache / PHP-FPM 側にタイムアウト・上限到達ログが残る
ハングアップ時の主なログ
# /var/log/httpd/error_log
[Wed Feb 16 08:36:14.373830 2026] [mpm_worker:error] [pid 2713:tid 2713] AH00286: server reached MaxRequestWorkers setting, consider raising the MaxRequestWorkers setting
# /var/log/php-fpm/error.log
[16-Feb-2026 07:50:28] WARNING: [pool www] server reached pm.max_children setting (50), consider raising it
# /var/log/httpd/error_log (一部)
[Wed Feb 16 07:52:12.750689 2026] [proxy_fcgi:error] ... AH01075: Error dispatching request to : (polling)
ポイントは、
MaxRequestWorkers と pm.max_children の両方が上限に達していることです。
リソース観測
同時に top を監視したところ、
ハングアップ直前は次の傾向が見られました。
- ロードアベレージが急騰（80超）
- CPU の idle がほぼ 0%
kswapd0の CPU 使用率が高騰- 空きメモリが急減し、スワップなし構成で回復不能に近い状態
この状態では、 Web リクエスト処理だけでなく OS の基本操作（SSH セッション処理）まで影響を受けました。
インスタンスタイプ変更での確認
「単純なスペック不足か」を切り分けるため、 インスタンスサイズを変更して同様の試験を実施しました。
t3.small（2 vCPU / 2 GiB）: 同様のハングアップを確認t3.medium（2 vCPU / 4 GiB）: 同様のハングアップを確認
メモリ増強だけでは根本解決せず、 接続・ワーカー制御の設定面に問題があると判断しました。
結論メモ
再現実験により、 ハングアップは偶発障害ではなく、 高負荷時にワーカー上限到達とメモリ圧迫が連鎖して発生することを確認できました。
偶発障害ではなく、設定と負荷条件で再現する事象だと判断しました。 次に Apache / PHP-FPM の上限設計を見直しました。