.NET ワーカー プロセスがクラッシュした場合、他のユーザーはどうなりますか?

Question

ASP.Net ワーカー プロセスによってプロセスがどのように処理されるかについての私の知識は、ひどく不十分です。専門家の何人かが私の意見を補ってくれることを願っています。

System.OutOfMemoryException でワーカー プロセスをクラッシュさせた場合、同じプロセスによって処理されている他のユーザーのユーザー エクスペリエンスはどうなりますか?空白の画面が表示されるでしょうか?503エラー？

私はこのシナリオを研究室の他の人々とテストしようとしていますが、これを外に出すつもりです。結果を更新します。

アップデート:結果はさまざまでした。人為的に OOM 例外を引き起こした場合 (たとえば、ますます大きな PDF をメモリにロードすることによって)、そのワーカー プロセスによって処理されている他のスレッドは一時的に「ハング」してから完了し、他のスレッドは戻らないように見えます。ご回答ありがとうございます。

Answer 1

W3WP.exeはプロセスです

IIS は、すべての Web アプリを汎用ワーカー プロセス (w3wp.exe) で実行します。ASP.NET、ISAPI、またはその他のフレームワークで作成する場合でも、Web リクエストを処理するプロセスは w3wp.exe です。ASP.NET の場合、w3wp.exe は ASP.NET JIT コンパイル済み DLL をロードし、それらを通じて要求を処理します。他の場合には、動作が異なります。しかし、重要な点は、w3wp.exe がプロセスであるということです。このモデルは IIS6.0 で開始され、IIS7.0 でも継続されます。

予期せぬ失敗

何らかの理由で W3WP.exe が予期せず失敗すると、処理していたすべてのトランザクションで 500 エラー (サーバー エラー) が発生する可能性があります。IIS は、代わりに新しいワーカー プロセスを開始します (MS はこれを「ヘルスモニタリング」と呼んでいます。)、これは Web アプリが引き続き実行されることを意味します。障害発生時に、障害が発生したプロセスによってリクエストが処理されていなかったユーザーは、このことには気づきません。

この場合にクライアントが受け取る HTTP 500 エラーは、アプリケーション エラー (ASPNET アプリケーション コードでキャッチされなかった例外など) の場合にクライアントが受け取る 500 エラーと区別できません。

失敗したプロセスにあったリ​​クエストを回復する方法はありません。ブラウザで 500 エラーが発生します。503 Server Busy は、IIS が接続数のしきい値のために接続を積極的に拒否したために発生します。503 はアプリケーションの障害によって発生するものではないため、メモリ不足とクラッシュのシナリオでは実行中のトランザクションで 503 が発生することは期待できません。負荷の高いシステムでは、プロセスのクラッシュと再起動が発生し、副次的な影響として 503 が発生することがあります。これが実際に発生している状況である場合は、単一エラー状態で負荷を処理するには、より大きな安全マージンが必要です。

リクエストキュー

IIS はリクエストをハンドオフするアプローチを採用しています. 。これらはネットワーク層 (Http.sys) に到着するとキューに入れられ、ワーカー プロセスによって取得されます。WP による処理を IIS キュー内で待機しているリクエストは影響を受けずに続行されますが、サーバー上で実行されているプロセスが 1 つ少なくなるため、リソースの競合により遅延 (サービス時間) が一時的にわずかに増加する可能性があります。適切に構成されたシステムでは、このキューでの待機時間は通常非常に短くなります。

このキューがいっぱいになると、503 エラーが表示されます。

W3WP.exeの自動再起動

IIS には自動再起動 (または「ナニー」) 機能があり、 ワーカープロセスが設定されたしきい値を超えた後に再起動します。, メモリ サイズ、リクエスト数、実行時間など。これらのすべてのケースで、構成されたしきい値に達すると、IIS はワーカー プロセスを休止して再起動します。これらのプロアクティブな再起動 通常は リクエストが中断されることはありません。IIS は、ワーカー プロセスの再起動が必要であると判断すると、その休止対象の WP に新しい要求が到着するのを防ぎます。 既存のリクエストは排出されます:その WP 内の実行中のトランザクションは正常に完了することができます。WP 内のすべての要求が完了すると、WP は終了し、代わりに IIS が新しい WP を開始します。この新しいプロセスは、すぐにディスパッチ キューから新しいリクエストを取得し始めます。これはユーザーやブラウザに対してすべて透過的です。

私は言う 通常は なぜなら、閾値に到達すると同時にワーカープロセスが本当に異常状態になっている可能性があるからです。その場合、w3wp.exe は次の期間内に IIS に応答しない可能性があります。 設定された「静止」タイムアウト, したがって、実行中のリクエストがすべて完了したことを報告していなくても、IIS は最終的にプロセスを強制終了する必要があります。これは 2 つの異なる例外的な条件であるため、これは非常にまれなはずですが、実際には起こります。この場合、処理中のリクエストで再び 500 エラーが発生します。

ウェブガーデン

また、IIS では単一サーバー上で複数のワーカー プロセスが許可されます。 MS はこれを「ウェブ ガーデン」と呼んでいます, 、「ウェブファーム」の言葉遊び。Web ガーデンが設定されている場合、障害が発生したインスタンス以外の w3wp.exe インスタンスによって処理されるトランザクションは影響を受けずに続行されます。ただし、「影響なし」では、メモリ不足エラーが局所的なものであり、システム全体の問題ではないことが前提となっています。

結論

肝心なのは、独自のテストに代わるものはないということです。構成オプションは、再起動のしきい値から Web ガーデンなどに至るまで、非常に多岐にわたります。また、メモリ、タイムアウト、ビジー状態など、障害モードは非常に複雑で多様になる傾向があります。何が起こるかを理解したいと思うでしょう。

ps:この Q&A は、実際には、serverfault.com に属します。

---

参考文献:
http://blogs.iis.net/thomad/archive/2008/05/07/the-iis-process-model-features.aspx

Answer 2

新しいワーカースレッドが開始され、ユーザーは何が起こったのか分からないでしょう。それは急速に障害が発生し、完全経由でシャットダウンしない限り（ます。http：// technet.microsoft.com/en-us/library/cc779127(WS.10).aspxする）

Answer 3

それは、メモリ不足の状態だ場合は、

は、単にアプリケーションプールをリサイクルする通常IISます。

Answer 4

他の回答が言うように

は、ほとんどの場合、すべてのものだけ再起動すると、その時の保留中の要求を持っていなかったほとんどのユーザーははるかに遅延よりも気付くことはありません。

アプリケーションがインプロセスセッション状態とセッション変数を使用する場合は、しかし、すべてのユーザーのすべてのセッション変数が時にアプリケーションプールの再起動失われます。これは、またはあなたがセッション変数でやっていることに応じて、ユーザーにマイナスの影響があってもなくてもよいです。あなたはは、StateServerまたはSQL Serverのセッションストレージに切り替えることで、これを回避することができます。