最近、ASP.NET アプリで奇妙な断続的な問題が発生しました。これらの問題には次のものが含まれます。
奇妙なことに、これらの問題は約 30 時間ごとに発生していました。「変だ」と私たちは思いました...
「アプリ プールのリサイクル プロパティのように聞こえる」と考えている方もいらっしゃると思います。あなたが正しい。私たちのアプリ プールは、自動的にリサイクルされる前にデフォルトの 1740 分に設定されていたため、状態や統計などが失われました。
私の要点は、IIS、ASP.NET、断続的なハングアップを引き起こす可能性のあるものがいくつかあります。あなたが遭遇したことは何ですか？
まず、
web.config ファイルを変更すると、アプリが再起動し、すべてのセッションが終了する可能性があります (InProc モードを使用している場合)。
どうもありがとう、
また、フレームワークに関連する未処理の例外が原因で、asp.net が実行される w3wp.exe プロセスがクラッシュする可能性を考慮することもできます。これが問題の一部である場合、w3wp.exe 処理が停止していることを明確に示すエントリが原因サーバーのシステムおよびアプリケーション イベント ログに見つかります。問題は、その理由を教えてくれないことです。何かが原因で機能が停止したことのみを記録します。
症状を軽減するには、InProc を状態サーバー (ローカルまたは SQL) に変更して、セッションを w3wp.exe プロセスから分離することから始めます。このプロセスがクラッシュしてもセッションは失われなくなりますが、最初の機会にメモリに復元されます。アプリケーション プールの設定を変更して、別の速度でリサイクルすることもできます。w3wp.exe がクラッシュしている場合は、より迅速にリサイクルする必要があり、「フェイル プロテクションを有効にする」を削除する必要があります。
ただし、これらはすべて問題を隠しているだけです。この性質の問題を切り分けるには、IIS Debug Diagnostic Toolをインストールして実行する必要があります。そのクラッシュ/ハング レポートは非常に有益であり、Asp.Net と IIS の間のあいまいな空間で発生する問題を見つけるのに非常に重要です。
セッションのトラブルシューティングのためだけに、これで十分です... http://aspalliance.com/1182
一方、ハングは他の多くの理由で発生する可能性があります。このような問題を修正する最善の方法は、windbgやDebug Diagnosticsなどのツールを使用して、問題が発生しているときにダンプを作成し、メモリダンプを作成することです。後で、これらのメモリダンプの問題を分析できます。
http://blogs.msdn.com/tessには、さまざまなシナリオのデバッグに関する多くの投稿があります。