個社利用環境にアクセスできません。リソース(CPU・メモリ・ディスク)のどれが原因か確認する方法を教えてください。

📌 前提

この記事は、個社利用環境にアクセスできない場合に、CPU・メモリ・ディスクのいずれのリソースが原因であるかを確認する方法について記載しています。
アクセスできない状況に対して、まず原因の切り分けを行いたい方向けの記事であり、各リソースにおける詳細な調査方法・対処方法については、本記事内の関連 FAQ を確認してください。

リソースの確認により把握できることは以下のとおりです。

  • CPU・メモリ・ディスクのうち、どのリソースに逼迫が発生しているか
  • 逼迫が発生している場合、想定される原因の方向性
  • 次にどの調査(サーバ再起動による暫定対応/各リソースの詳細調査)に進むべきか

なお、リソース確認の結果、いずれのリソースにも異常が見られない場合は、AWS基盤側の問題である可能性もあります。
この場合はお客様側での切り分けが困難なため、Accel-Mart Plus サービスサポート窓口へ問い合わせてください。
お問い合わせに必要な情報については、本記事末尾の「補足事項」を確認してください。

 

なお、原因調査よりも復旧を優先したい場合は、以下を確認してください。
 

・個社利用環境にアクセスできない場合の緊急対処方法を教えてください。
https://cloud.intra-mart.support/hc/ja/articles/62702967448857 

 

ステップ1:サーバのリソース(CPU・メモリ・ディスク)を確認する

調査を行う際には、必要に応じて運用管理機能の「リソース表示」より、事象発生時刻や、事象発生時点のCPU・メモリの使用率の状況などのリソース情報を確認してください。

「リソース表示」の操作方法、および、表示仕様については、以下を確認してください。

■Accel-Mart Plus 運用者操作ガイド - リソース表示
https://aws.accel-mart.com/am_document/texts/system_operation/resource_display/index.html 

確認した使用率の状況に応じて、以下から該当する症状を探してください。
なお、複数のリソースに同時に異常が見られる場合や、一見異常が見られなくても原因となっているケースもあるため、該当しそうな症状が複数ある場合は、いずれもご確認いただくことを推奨します。

 

■ CPU使用率が100%に近い場合

【APサーバ側のCPU使用率が高い場合】

原因:特定リクエスト・処理への負荷集中や、処理のループ等の異常な高負荷が考えられます。
対処法:負荷の原因となっているリクエスト・処理の特定が必要です。具体的な調査方法については、以下の関連FAQを確認してください。

・CPU使用率やロードアベレージが上昇しています。対応方法を教えてください。
https://cloud.intra-mart.support/hc/ja/articles/17161895455001
📁 事例より
特定の重い処理が同時に実行されCPUを占有するケースなどが確認されています。

【お問い合わせ事例集 / 特定処理の負荷集中起因】
APサーバーのCPU使用率が99%超過で継続する問題
https://cloud.intra-mart.support/hc/ja/articles/53698952901145

 

【DBサーバ側のCPU使用率が高い場合】

原因:画面操作の繰り返しや、特定の処理に紐づくSQL(階層検索、集計処理等)の負荷が考えられます。
対処法:まずAPサーバの再起動を実施し、事象が改善するか確認してください。APサーバの再起動方法については、以下のドキュメントを確認してください。
※緊急対処にて既にAPサーバの再起動を実施済みの場合は、本手順は実施済みとしてご確認のうえ、改善しない場合は次にDBサーバの再起動を実施してください。DBサーバの再起動方法については、以下のドキュメントを確認してください。
 

■Accel-Mart Plus 運用者操作ガイド - サーバを再起動する
https://aws.accel-mart.com/am_document/texts/system_operation/system_information.html#server-restart
■Accel-Mart Plus 運用者操作ガイド - DBサーバを再起動する
https://aws.accel-mart.com/am_document/texts/system_operation/system_information.html#db
⚠️ 注意
APサーバの再起動を実施しても、DBサーバは再起動されません。
DBサーバ側の負荷が原因の場合は、別途DBサーバの再起動が必要です。
DBサーバの再起動は時間がかかるため、まずAPサーバの再起動で改善するかを確認してください。


いずれの再起動でも改善しない場合は、原因となっている処理・SQLの特定を行ってください。
 

📁 事例より
特定のロジックフロールーティングに紐づくSQLが高負荷になったケース、ViewCreatorの画面操作に紐づくSQLが高負荷になったケースなどが確認されています。

【お問い合わせ事例集 / ViewCreator操作に紐づくSQL起因】
ViewCreator画面でのSQL実行によるDBサーバCPU使用率99%超過
https://cloud.intra-mart.support/hc/ja/articles/51825866385561

 

■ メモリ使用率が100%に近い場合、または、一見正常に見える場合

【APサーバ側のメモリ使用率が高い場合】

原因:特定処理でのメモリ大量消費(大量データ処理、マスタ不備等による無限ループ、ジョブネットの一括処理等)により、Javaヒープメモリが枯渇(OutOfMemoryError)している可能性があります。
対処法:メモリの使用率が上昇する原因を特定する必要があります。

・メモリ使用率が上昇しています。対応方法を教えてください。
https://cloud.intra-mart.support/hc/ja/articles/21579774858265 
⚠️ 注意
リソース表示上のメモリ使用率が正常な値であっても、Javaヒープ領域のみが枯渇し、サーバダウン・再起動が発生しているケースがあります。
監視アラートの対象はAPサーバ全体のメモリ使用率(Javaヒープ領域に限らないメモリ全体)であるため、監視アラートのしきい値に達せず、アラートメールが送信されないことがあります。
運用管理サイトの「リソース表示」でメモリ使用率に異常が見られない場合でも、JVMログにOutOfMemoryError等のエラーが出力されていないかを併せて確認することを推奨します。

JVMログ内の具体的なエラー文言(例:OutOfMemoryError等)から原因を特定したい場合は、次のステップにて確認方法・エラー例を案内していますので、そちらを確認してください。

ステップ2:Resin JVMログを確認する(エラー文検索)近日公開

※現在準備中の項目です。今後、内容を順次公開予定です。

📁 事例より
特定処理(大量データ抽出等)でヒープを使い切ったケース、マスタ設定不備による無限ループで OOME を引き起こしたケース、ジョブネットの一括データ処理でヒープが枯渇したケースなどが確認されています。いずれもリソース表示上は異常が見られないことがあります。

【お問い合わせ事例集 / マスタ不備の無限ループ起因】
APサーバダウン(OutOfMemoryError)の原因調査と対処
https://cloud.intra-mart.support/hc/ja/articles/50804515495705

 

■ ディスク使用率が100%に近い、または、空きストレージ容量が0に近い場合

【APサーバ側のディスク使用率が高い場合】

原因:ログファイルの肥大化(主にログレベル「DEBUG」での出力)、大きなサイズのファイルのアップロード、ヒープダンプ等がディスクを圧迫しているケースが考えられます。
対処法:大容量ファイルの特定・削除、または、ログレベルの見直しを実施してください。具体的な調査方法については、以下の関連FAQを確認してください。

・ディスク使用率が上昇しています。対応方法を教えてください。
https://cloud.intra-mart.support/hc/ja/articles/21867240222105 
⚠️ 注意
Accel-Mart Plus ログファイルの肥大化が原因の場合、ご契約者様が削除操作を行えるのは同期先(PublicStorage)のファイルのみです。
Accel-Mart Plus 環境のログファイルは、同期元から同期先へ5分単位で同期される仕組みのため、同期先のファイルを削除しても同期元のファイルは削除されず、ディスク使用率は減少しません。
そのため、ディスク使用率の恒久的な解消には、ディスク使用率が上昇する前の時点のバックアップからのリストアを検討してください。リストアの操作方法については、以下のドキュメントを確認してください。

■Accel-Mart Plus 運用者操作ガイド - リストア
https://aws.accel-mart.com/am_document/texts/system_operation/restore.html 
📁 事例より
環境ログの肥大化(DEBUGログ大量出力)によりディスク使用率が100%に達したケース、無限ループ処理により大量のログが出力されディスク容量を圧迫したケース、ヒープダンプの出力によりディスクを圧迫したケースなどが確認されています。

【お問い合わせ事例集 / 無限ループ処理起因】
LogicDesigner無限ループによるディスク容量逼迫とサービス停止
https://cloud.intra-mart.support/hc/ja/articles/52312283309721

【お問い合わせ事例集 / ディレクトリ等の蓄積起因】
ディスク容量100%によるログイン不可とSFTPでのファイル削除方法
https://cloud.intra-mart.support/hc/ja/articles/52515950415257

 

【DBサーバ側の空きストレージ容量が0に近い場合】
原因:RDSのストレージ容量の空きが少なくなっており、このまま使用が続くと、ストレージ容量が完全に枯渇(storage-full化)し、DBへの接続自体ができなくなる可能性があります。
対処法:ストレージ容量が完全に枯渇する前に、不要なデータの削除、または、リストアによる事象改善を検討してください。リストアの操作方法については、以下のドキュメントを確認してください。

■Accel-Mart Plus 運用者操作ガイド - リストア
https://aws.accel-mart.com/am_document/texts/system_operation/restore.html 
⚠️ 注意
リストアを実施すると障害発生時のログが失われ、以降の原因調査が困難になります。
原因調査実施を検討されている場合は、可能な限りリストア前にログを退避しておくことを検討してください。
⚠️ 注意
ストレージ容量が完全に枯渇(storage-full化)すると、DBへの接続自体ができなくなり、ご契約者様側での対応(データ削除、リストア等)が行えなくなる可能性があります。この状態では、DBサーバの再起動やリストアを実施しても正常に完了しない可能性があるため、速やかにAccel-Mart Plusにサービスサポート窓口へ問い合わせてください。
📁 事例より
大量データインポート操作によりRDSストレージ容量が枯渇したケースが確認されています。

 

上記のいずれの症状にも当てはまらない場合や、リソース確認のみで原因が特定できない場合は、 続いてResin JVMログ・リクエストログの確認を進めてください。

ステップ2:Resin JVMログを確認する(エラー文検索)近日公開

ステップ3:リクエストログを確認する(ステータスコード・処理時間)近日公開

※現在準備中の項目です。今後、内容を順次公開予定です。

 

📌 補足事項

・原因調査の結果、ご契約者様にて独自に開発されたアプリケーションやSQL等が原因と判断された場合は、ご契約者様にて対応を実施してください。

・弊社が構築し提供している範囲(OS、ミドルウェア製品、および、弊社Accelシリーズ製品)が起因と判断され、対応が必要な場合は、Accel-Mart Plusサービスサポート窓口へ問い合わせてください。
その際は、弊社提供範囲が起因と判断された理由についてもあわせて記載してください。

・障害調査に関する問い合わせの場合、問題の切り分けや、問い合わせに必要な情報の準備が必要です。

■ Accel-Mart Plus お問い合わせガイド - 障害調査
https://aws.accel-mart.com/support_inquiry_guide/texts/inquiry_process/support_category_decision/failure_analysis.html

・Accel-Mart Plusサービスサポート窓口へのお問い合わせに必要な情報については、以下のドキュメントを確認してください。

■ Accel-Mart Plus お問い合わせガイド - 問い合わせに必要な情報の準備
https://aws.accel-mart.com/support_inquiry_guide/texts/inquiry_process/support_category_decision/failure_analysis.html#prepare-failure-analysis-inquiry

 

この記事は役に立ちましたか?
0人中0人がこの記事が役に立ったと言っています
Powered by Zendesk