IISログからアプリケーションプールのクラッシュを診断する方法は？

アプリケーションプールのクラッシュは、IISログを分析することにより、原因をすばやく見つけることができます。 1.最初に、クラッシュ時点でW3SVCログを確認し、503エラーを検索し、アプリケーションプールのクラッシュまたは頻繁なリサイクルによって引き起こされるかどうかを判断します。 2。HTTPERRログと組み合わせて、Connection_DroppedやRequestQueUefullなどの根本的なエラーエントリがあるかどうかを確認し、バックエンドが応答できないことを確認します。 3.イベントビューアーのアプリケーションとシステムログを確認し、5002、5015、5017からのイベントを見つけました。 4.コードの例外、依存関係の利用不能、急速な障害トリガー、メモリリークなどの一般的な原因をトラブルシューティングし、デバッグツールとパフォーマンスモニターを組み合わせてさらに分析します。マルチログの相互検証を通じて、問題の範囲を徐々に狭めます。

あなたのウェブサイトがIISで実行されると、アプリケーションプールがクラッシュするという問題に遭遇することがあります。イベントの視聴者とログはいくつかの手がかりを提供できますが、多くの場合、真に有用な情報がIISのログファイルに隠されています。これらのログを分析することにより、問題を解決するために推測や再起動に頼るのではなく、問題の根本原因をより速く見つけることができます。

IISログの例外時点を表示します

デフォルトでは、IISはC:\inetpub\logs\LogFilesディレクトリにログファイルを生成し、各サイトには個別のフォルダーがあります。まず、アプリケーションプールがクラッシュする概算時間を確認し、対応する期間のログエントリを見つける必要があります。

一般的な慣行は次のとおりです。

• クラッシュの前後に数分かかるログファイルを開きます
• ステータスコード503でリクエストを検索します（サービスは利用できません）
• 連続503エラーに注意してください。これは通常、アプリケーションプールがクラッシュしたか、頻繁にリサイクルされていることを意味します

503エラーは常にアプリケーションプールのクラッシュによって引き起こされるわけではありませんが、重要な信号です。アプリケーションプールのスタートアップ時間と故障制限と組み合わせることで、高速障害保護メカニズムのためにアプリケーションプールが無効になっているかどうかを判断できます。

W3SVCログとHTTPERRログ交差分析を組み合わせます

IIS独自のW3SVCログ（サイトごとにアクセス情報を記録）に加えて、 C:\Windows\System32\LogFiles\HTTPERRにある別の見過ごされがちなHTTPERRログがあります。

これら2つのログの違いは次のとおりです。

• W3SVCログ：ユーザーがアクセスしたページや返されたステータスコードなど、成功または失敗したHTTP要求の詳細を記録します。
• HTTPERRログ：接続タイムアウト、プロトコルエラー、サーバービジーなど、より根本的なエラーを記録します。

Connection_DroppedやRequestQueueFullなどの多数のエントリがHTTPERRに表示されると、バックエンドアプリケーションプールがリクエストに応答できなくなっていることを示し、アプリケーションプールのクラッシュまたはハングをさらに実証します。

ログを見ることに加えて、システムログとアプリケーションログを確認します

IISログ自体では、アプリケーションプールがクラッシュする理由はわかりません。詳細な診断を受けるには、確認する必要があります。

• Windowsイベントビューアー→アプリケーションログとシステムログ
• WAS （Windows Process Activation Service）またはIIS-WMSVCからのエントリを見つける
• イベントIDに注意してください： 5002、5015、5017およびアプリケーションプールのライフサイクルに関連するその他のイベント

たとえば、イベントID 5002のログが表示されている場合、「リサイクルに失敗したために「アプリケーションプール」myApppool」が無効になっているように見える場合、リサイクルに失敗したため、アプリケーションプールが無効になっていることを意味します。

さらに、 IISに対して障害のある要求トレースが有効になっている場合、より詳細なエラースタック情報を取得できます。

一般的な原因と調査の提案

ログから手がかりを見つけた後、次のステップは特定の理由を見つけることです。アプリケーションプールのクラッシュを引き起こすいくつかの一般的な原因とトラブルシューティング方法は次のとおりです。

• コード例外は処理されていません
  たとえば、.NETのnullReferenceExceptionまたはstackoverflowexceptionは、W3WP.EXEプロセスをクラッシュさせます。 Debugdiagなどのデバッグツールを使用して、 Windowsエラーレポート（WER）を有効にするか、メモリダンプを生成することにより、さらに分析できます。

• サービスやリソースへの依存は利用できません
  データベースに接続できないこと、サードパーティのコンポーネントのロードに失敗したこと、許可不十分などの問題も間接的にクラッシュを引き起こす可能性があります。データベース接続タイムアウトやcomコンポーネントコールの障害などのキーワードがあるかどうかを確認してください。

• 高速障害保護トリガー
  アプリプールが頻繁にクラッシュする場合（1分あたり複数回など）、IISはアプリプールを自動的に無効にします。アプリプール設定のクイック障害保護オプションを確認し、しきい値を適切に調整します。

• メモリリークまたは過度の使用
  ログに明らかなエラーがないが、アプリケーションプールが定期的にクラッシュする場合、メモリの使用量が制限を超える可能性があります。 Performance Monitor（Perfmon）を使用して、w3wp.exeのメモリ使用傾向を表示できます。

基本的にそれだけです。アプリケーションプールのクラッシュの診断は1段階のタスクではなく、複数のログソースの相互検証が必要です。重要なのは、IISログから始めて、例外の時点を見つけてから、システムログと実際のコード動作でスコープを徐々に狭めることです。

以上がIISログからアプリケーションプールのクラッシュを診断する方法は？の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。