応答しない/ハングした/壊れたIIS Webサイトを解決しようとするときに実行する手順は何ですか？
IIS Webサイトが応答していない場合、どのような手順を実行しますか？
最初に指定されたポートにTelnetで接続し、次にWebサイトのバインドと認証を確認して、最後に再起動しようとする場合があります。
このような問題に直面したときに経験豊富な管理者が何をチェックするかを知ることは非常に役立つと思います。
実際、私は30分以上かけて何が問題なのかを理解しようとしましたが、何も間違っているようには見えませんでした。 Webサイトを再起動しただけで問題は解決しましたが、IISサービスを再起動すると、問題は解決しました。
より良いトレースまたは少なくともそれをより速く解決するのに役立つ便利なロギング機能を知ることができれば、30分以上節約できます。
{FYI使用していますIIS 7.5}
次のガイダンスは、一般的なコレクションガイドとして非常にうまく機能することがわかりました。
症状の特定
問題の表面積を（できるだけ早く）確立するようにしてください。
接続性？（Telnetは良好です。ブラウザにエラーページが返される場合は、明らかに機能しています-最初に接続性を排除してください）
一般的なアプリプールの失敗、またはコンテンツタイプに固有ですか？（ASPXファイルは機能しますか/機能しませんが、.HTMは機能しますか？各アプリとコンテンツのカナリアファイルはありますか？タイプ？）
特定のアプリ内障害、ハング、またはクラッシュ？（これのほとんどはハングとアプリの障害のためです。クラッシュは独自の方法論を決定します：クラッシュダンプを取得し、デバッグします）
原則として、複数の症状に対処している可能性があるため、常にそれを書き留めてください。以前のインシデントに関するメモを参照できることは非常に貴重です。
データ収集
別名「時間データの収集」-停止中に特定のデータを収集するためのウィンドウは限られています。プロセスメモリなどの一部のデータは一時的なものであり、最初に修正措置を講じると消えます。ログなどの他のデータはコピーに時間がかかる場合がありますが、後で簡単に取得できます。したがって、今すぐ収集する必要があるデータと復元後のデータを理解してください。
何でも取得します時間に敏感な/タイムリーなデータ後で問題を解決する必要があります。永続的なものについて心配する必要はありません-イベントログとIISログは、あなたが強迫的に明確でない限り、残ります：それを止めてください。（先週のイベントログを持っていない人はそれを繰り返す運命にあります）
影響を受けるワーカープロセスを決定します（そしてそれをダンプします）
APPCMD LIST WPはこれを支援するか、Worker Processes GUIServerレベルで役立ちます。GUIを使用している場合は、ワーカープロセスを右クリックして現在のリクエストを確認することを忘れないでください。取得すると、リクエストがどのモジュール（DLL）に詰め込まれているかが表示され、推測に役立ちます。早期に引き起こします。
scopeを決定します（つまり、1つのアプリプール、複数のアプリプール、依存関係のある2つ-これはアプリとウェブサイトのレイアウトによって異なります）
メモリダンプを取得ワーカープロセス-問題のあるアプリプールを特定したら、関連するワーカープロセスを特定し、タスクマネージャーを使用してメモリダンプを作成しますそのプロセスを右クリックします。後で使用するためにファイル名をメモします。
- タスクマネージャーのビット数に関する注意：32ビットのWP）をダンプする場合は、攻撃しているワーカープロセスとタスクマネージャーと同じビット数を使用する必要があります。 =（w3wp * 32）64ビットタスクマネージャーでは、解釈できません。64ビットWindowsで32ビットプロセスをダンプする場合は、タスクマネージャーを終了し、％WINDIR％\ SYSWOW64\TaskMgr.exeを実行する必要があります。 32ビットバージョンを取得するには、同じビット数でダンプします（10秒の迂回ですが、その時点で実行する必要があります）。
サービスの復元
これで、診断に必要と思われるすべての時点情報が得られたので、Webサイトの顧客をビジネスに戻す時が来ました。
リサイクルワーカープロセスの最小数サービスを復元するため。
わざわざウェブサイトを停止したり開始したりしないでください。通常、サイトを再び機能させるにはアプリプールを更新する必要があります。これがリサイクルの機能です。
アプリプールのリサイクルは9/10倍で十分です。
（既存のWPはなくなるように言われていますが）次のリクエストでリサイクルが行われるように見えるので、ワーカープロセスは行わない可能性があることに注意してくださいすぐに再表示されます。これは、機能していないという意味ではなく、待機しているリクエストがないということです。
IISResetは通常、よく知らない人が使用するツールです。 使用しないでください必要がない限りすべてのWebサイトを一度に終了して再起動する。 （レンガで壁に釘を打ち込もうとするようなものです。うまくいくかもしれませんが、あなたはちょっと馬鹿のように見え、ある時点で巻き添え被害が発生するでしょう） 。
他のアプリの依存関係がある可能性があります-他のアプリプール、データベース、または外部システムに依存するアプリプール...サービスを復元するために必要なことは、問題の範囲について何かを教えてくれます。リストの最後は完全な再起動ですが、カーネルレベルのドライバーが実際に混乱していない限り、通常は必要ありません。必要なものを判断できないだけで、便利なキャッチオールです...
原因の特定つまり、収集したデータを見て考えます。
- ログとメモリダンプを取得し、共通点を探し、アプリ開発者を関与させ、 DebugDiag （またはそれ以降）またはWinDBGでダンプをデバッグします。
次回の設定
あなたはそれを修正したことを知っていますか？そうでない場合、特に他に何も変わっていないように思われる場合は、再度発生した場合にセットアップを改善した場合に、何をキャプチャできるかを考えてください。
それが最後の発生であると思い込まないでください-計画を開発します次回収集する必要があるもの、ベース今回は。
たとえば、リクエストがすべて同じURLに対するものである場合は、追加のインストルメンテーションまたはロギング、または問題が発生しているページ上のスポットを特定するのに役立つ失敗したリクエストトレースルールを実装します。
パフォーマンスモニターログは役に立ちます（疑わしい場合は、perfmonログも取得してください）。
役に立つかもしれない他のツールを見てください-ProcDump、XPerf/WPT/WPRなど。あなたが持っているのがハンマーだけなら、すべての問題は釘でなければなりません…
実際の根本原因を探しながら、問題の「ペーパーオーバー」が許容できるかどうかを検討します。停止が本当にひどい場合は、アプリプールのリサイクル設定を調整して、可能性や期間を最小限に抑えることができる場合があります（競合する場合を除く）。トラブルシューティングできるように）...
バインディングまたは認証方法（静的である必要があります）によってサイトが応答しなくなるのはなぜですか？それらは私の小切手のリストに載っていないか、少なくとも私のリストの一番上に載っていないでしょう。
最初に確認するのは、サイトがサーバー自体から読み込まれるかどうかです。そうでない場合は、考えられるほとんどすべてのネットワークまたはDNSの問題を原因として除外できます。