ASP.Net ワーカー プロセスによってプロセスがどのように処理されるかについての私の知識は、ひどく不十分です。そこにいる専門家の何人かが私を埋めてくれることを願っています。
System.OutOfMemoryException でワーカー プロセスをクラッシュさせた場合、同じプロセスによって処理されていた他のユーザーのユーザー エクスペリエンスはどうなりますか? 彼らは空白の画面を取得しますか? 503エラー？
私はこのシナリオを私たちの研究室の他の人々と一緒にテストしようとしていますが、私はこれをそこに浮かび上がらせると思いました. 結果を更新します。
更新: 結果はさまざまでした。人為的に OOM 例外を誘発した場合 (たとえば、ますます大きな PDF をメモリにロードすることによって)、そのワーカー プロセスによって提供されている他のスレッドは一時的に「ハング」してから完了しますが、他のスレッドは決して戻らないように見えます。ご回答ありがとうございます。
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 エラーは、アプリケーション エラーの場合にクライアントが受信する 500 エラーと区別がつきません。たとえば、ASPNET アプリケーション コードでキャッチされない例外が発生したとします。
失敗したプロセスにあったリクエストについては、それらを回復する方法はありません。ブラウザで 500 エラーが発生します。503 Server Busy は、接続数のしきい値が原因で IIS が積極的に接続を拒否したために発生します。503 はアプリケーションの障害によるものではないため、メモリ不足とクラッシュのシナリオで実行中のトランザクションに 503 が表示されるとは考えないでください。負荷の高いシステムでは、二次的な影響として、プロセスのクラッシュと再起動が発生すると 503 が表示される場合があります。これが実際に表示されているものである場合は、単一エラー状態で負荷を処理するために、より大きな安全マージンが必要です。
IIS には、要求に対するハンドオフ アプローチがあります。それらがネットワーク層 (Http.sys) に到達すると、キューに配置され、ワーカー プロセスによって取得されます。WP によって処理されるために IIS キューで待機している要求は影響を受けませんが、サーバーで実行されているプロセスが 1 つ少ないため、リソースの競合により一時的に待ち時間 (サービス時間) がわずかに増加する可能性があります。適切に構成されたシステムでは、通常、このキューでの待機時間は非常に短くなります。
このキューがいっぱいになると、503 エラーが表示されます。
IIS には自動再起動 (または「ナニー」) 機能があり、ワーカー プロセスがメモリ サイズ、要求数、実行時間などの構成されたしきい値を超えた後に再起動します。いずれの場合でも、構成されたしきい値に達すると、IIS はワーカー プロセスを停止して再起動します。通常、これらのプロアクティブな再起動により、リクエストが中断されることはありません。IIS は、ワーカー プロセスの再起動が必要であると判断すると、新しい要求が休止する WP に到達するのを防ぎます。既存のリクエストは排出されます: その WP 内の進行中のトランザクションは、正常に完了することができます。WP 内のすべての要求が完了すると、WP は終了し、IIS は代わりに新しいものを開始します。この新しいプロセスは、すぐにディスパッチ キューから新しい要求を取得し始めます。これはすべて、ユーザーまたはブラウザーに対して透過的です。
私が普通に言っているのは、しきい値に達したと同時にワーカー プロセスが本当に異常になった可能性があるためです。その場合、w3wp.exe は構成された「静止」タイムアウト内に IIS に応答しない可能性があるため、処理中のすべての要求が完了したことを報告していなくても、IIS は最終的にプロセスを強制終了する必要があります。これは 2 つの異なる例外的な条件であるため、非常にまれなはずですが、実際に発生します。この場合、進行中のリクエストは再び 500 エラーを受け取ります。
また、IIS では、1 つのサーバー上で複数のワーカー プロセスを使用できます。 MS はこれを「Web ガーデン」と呼んでいます。これは「Web ファーム」の言葉遊びです。Web ガーデンがセットアップされている場合、失敗したインスタンス以外の w3wp.exe インスタンスによって処理されているトランザクションは影響を受けずに続行されます。ただし、「影響を受けない」とは、メモリ不足エラーが局所的なものであり、システム全体の問題ではないことを前提としています。
肝心なのは、独自のテストに代わるものはないということです。構成オプションは、再起動のしきい値から Web ガーデンなど、非常に幅広いものです。また、障害モードは、メモリ、タイムアウト、ビジー状態など、非常に複雑で多様になる傾向があります。何を期待するかを理解したいと思うでしょう。
ps: この Q&A は実際には serverfault.com のものです !!
参照:
http://blogs.iis.net/thomad/archive/2008/05/07/the-iis-process-model-features.aspx
新しいワーカー スレッドが開始され、ユーザーは何が起こったかわかりません。ラピッド フェイルによって完全にシャットダウンしない限り ( http://technet.microsoft.com/en-us/library/cc779127(WS.10).aspx )
メモリ不足の状況の場合、通常、iis はアプリ プールをリサイクルするだけです。
他の回答が言うように、ほとんどの場合、すべてが再起動するだけであり、その時点で保留中のリクエストを持っていなかったほとんどのユーザーは、遅延以上のものに気付かないでしょう.
ただし、アプリケーションが In-Proc セッション状態のセッション変数を使用する場合、アプリケーション プールが再起動すると、すべてのユーザーのすべてのセッション変数が失われます。これは、セッション変数で何をしているかに応じて、ユーザーに悪影響を与える場合としない場合があります。これは、StateServer または SQL Server セッション ストレージに切り替えることで回避できます。