障害切り分け_sarで見るサーバー高負荷

障害切り分けフロー「SmartDBへのアクセスに時間がかかる」「SmartDBへアクセスできない」で解決できない場合、次の「sarで見るサーバー高負荷」を参考に障害の原因がどこにあるか確認しましょう。

注意事項

調査に必要なログを取得せずに復旧した場合、原因の特定ができない場合があります。
原因の特定を優先する場合はApacheの起動や、プロセスのKillをしないでください。

障害切り分けフロー

 

※ フロー図のダウンロードはこちらから

  1. CPUを占有している原因を特定のうえ、アプリケーション以外（OSなど）をご確認ください。
  2. 必要情報をご準備のうえ、サポートセンターへお問い合わせください。
  3. CPUを占有しているプロセスを特定のうえ、原因を調査してください。
  4. 不要なファイルを削除もしくは退避してください。
    • リビジョンアップ時に使用したモジュールのアーカイブや展開済みのディレクトリがそのままになっている場合があります。通常は/tmp配下に展開しますのでご確認ください。
    • アクセスログやエラーログが大量に残っている場合があります。/home/DreamArts/logs/insuite/配下をご確認ください。
    • 今後の予防策として、ディスクの使用量を監視対象に含める事をおすすめします。
  5. 長時間使用されていないメモリをSwap領域に移しただけの可能性があるため、一定期間は静観してください。事象が再発し、原因調査が必要な場合はサポートセンターへお問い合わせください。
  6. Tomcat上で動作しているLuxorなどの場合、起動パラメーターなどで割り当てメモリ量を増やすことにより事象が解消する可能性があります。
  7. サーバー全体のメモリが枯渇しています。メモリ枯渇の原因は次の通りです。該当しない場合はサーバーのスペックや利用状況、事象発生時のsar情報などを取得してサポートセンターへお問い合わせください。
    • 設定値がサーバーのスペック以上である
    • メモリを大量に消費する処理が実行中
    • 製品の不具合でメモリリークが発生
    • 利用量増加によりサーバーのスペック不足
  1. 切り分けができませんでした。I/Oが増加した原因を調査してください。調査の結果、製品が原因だと疑われる場合、調査結果と必要情報をご準備のうえ、サポートセンターへお問い合わせください。
  2. ディスクのマウント、NFSとの接続などの観点で原因を調査してください。

必要情報

  • 事象発生の日時を教えてください
  • 事象発生時と平常時のsar情報を取得してください
  • クライアント側にエラーが出力されますか？
  • 事象発生時のシステムチェック用アーカイブ（アクセスログありで、全サーバー分）を取得してください
  • 各APサーバーで、下記コマンドの実行結果を教えてください
     # ps aux
# df -h
# vmstat -n 1 3
# top -b -n 1
  • SmartDB APサーバーのファイル（事象発生時） 
     /etc/hibiki/hibiki.xml
/etc/hibiki/default.xml
  • SmartDB APサーバーのファイル（事象発生時) 
     /var/log/hibiki/access.log.yyyymmdd
/var/log/hibiki/audit.log.yyyymmdd
/var/log/hibiki/hibiki.log.yyyymmdd
/opt/jakarta-tomcat/logs/catalina.out

 

 

このセクションの記事

この記事は役に立ちましたか？
0人中0人がこの記事が役に立ったと言っています
おさがしの情報がない場合は、こちらからお問い合わせください。

関連記事