質問
⚠️ この事例は公開されてから1年以上経過しています。 情報が古い可能性がありますので、ご注意ください。
🕓 事例公開日 : 2025-04-08
【背景】
開発環境のAPサーバで高負荷なSQL処理を実行したところ、サーバが停止して「メンテナンス中です」の画面が表示された。通常であれば自動再起動が動作するはずだが、今回は動作しなかった。1. 事象
エラーメッセージ・スタックトレース：
[25-03-12 17:29:04.530] {resin-2014} AnomalyAnalyzer Resin|Http|Request Time WARNING1211.571 sample is 2684.48% of 45.132 avg, 12.092 std deviations (std=96.465, n=738.0)[25-03-12 17:29:48.403] {CoordinatorThread[]-3} AlarmClock slow alarm Alarm[alarm[com.caucho.server.admin.JniNetStat@1d01dfa5]] 24263ms coordinator-delta 29160ms[25-03-12 17:29:48.403] {CoordinatorThread[]-3} AlarmClock slow alarm Alarm[alarm[com.caucho.cloud.heartbeat.HeartbeatActor$HeartBeatAlarm@3402b4c9]] 31613ms coordinator-delta 36615ms[25-03-12 17:29:48.403] {CoordinatorThread[]-3} AlarmClock slow alarm Alarm[alarm[com.caucho.server.distcache.DataStore$DeleteAlarm@4c59e45e]] 26592ms coordinator-delta 36615ms
症状の説明：
・高負荷SQL処理実行後にサーバが応答しなくなった・「メンテナンス中です」の表示が継続した
・自動再起動機能が動作しなかった
・手動でサーバ再起動を実行して復旧した
2. 発生条件
・開発環境（Developmentプラン）でのSQL処理実行時・高負荷なSQL処理によりサーバリソースが枯渇した状況
・17:30頃に処理開始、17:54に手動再起動実施
回答
1. 原因
技術的な原因：
高負荷SQL処理によりメモリが枯渇し、Javaアプリケーションの動作が停滞したため、ヘルスチェック機能が正常に動作できなくなったことが原因です。技術的要因の分析：
・高負荷SQL処理の実行 → メモリリソースの大量消費・メモリ枯渇状態の発生 → Javaプロセスの動作停滞
・AlarmClockスレッドの遅延 → システム内部処理の大幅な遅延（24秒〜36秒）
・ヘルスチェック処理の停止 → 自動再起動トリガーの無効化
・CoordinatorThreadの機能不全 → ハートビート機能やデータストア処理の停止
根本的な要因：
メモリ枯渇により、自動再起動の前提となるヘルスチェック機能自体が動作不能になったため、システムの自己回復機能が働かなかった状況です。2. 対応方法
根本解決方法：
1. 高負荷SQL処理を実行する前に、処理対象データ量とメモリ使用量を事前に見積もる2. 大量データ処理時は、バッチ処理やページング処理に分割して実行する
3. SQL処理の実行計画を事前に確認し、インデックスの最適化を行う
暫定対処方法：
同様の事象が発生した場合は、管理者サイトからの手動再起動により復旧可能です。メモリ枯渇が疑われる場合は、速やかに再起動を実施してください。3. 原因究明に至るまでの調査方法
1. サーバ停止時刻とエラー発生タイミングの特定2. アプリケーションログ（jvm-app-0.log）の詳細分析
3. AlarmClockスレッドの遅延時間測定（24秒〜36秒の遅延を確認）
4. メモリ使用状況とJavaプロセスの動作状態の検証
5. ヘルスチェック機能の動作可否の確認
6. 自動再起動機能の前提条件との照合