IIS 7.0。の独自のアプリケーションプールで実行されているWebサイトアプリケーションがあります。アプリケーションはASP.NET MVC 3 Webサイトです。
W3wp IISワーカーサービスはかなり高い(800 MB、多少変動します)に対応するこのアプリケーションのメモリ使用量に気付きました。
問題を診断しようとしていますが、次のことを試しました。
IISレベルでWebサイトの出力ページキャッシングを無効にし、アプリケーションプールをリサイクルしました。これにより、w3wpプロセスが再起動します。このプロセスのメモリ使用量は、徐々に800 MB 、これには約30秒かかります。この時点で処理されているページリクエストはありません。IISプロセスのメモリサイズは変わりません。
VS 2010からアプリケーションのデバッグコピーを実行しようとしましたが、メモリ使用量に問題はありません。
私が持っているいくつかのアイデア/質問は:
この問題はWebサイトのコードに関連していますか? -ページリクエストが送信/処理される前にメモリが急増する場合、これはコードの問題ではないと思いますか?
MVCで構築されたアプリケーションには、キャッシングの処理が書き込まれていません。
Webサイトはデータのリアルタイム表示を使用し、ajaxリクエストを定期的に使用し、通常は長期間「オープン」のままです。
アプリケーションがリサイクルされ、ユーザーリクエストが送信されなかった後、メモリ使用量が急増するのはなぜですか?これは、古いキャッシュ情報をディスクからメモリに読み込んでいるからですか?
アプリケーションがクラッシュすることはありません。メモリの使用量を心配しているだけで、ウェブサイトほど大きくはありません...
この問題を解決するためのアイデアやヘルプをいただければ幸いです。
サーバーを見るだけで、プールは900〜1000 MBの仮想サイズのメモリと380 MBのワーキングセットを使用します。私のサイトはここ数年問題なくスムーズに稼働しており、すべての側面からそれらをチェックしています。私のプールは決してリサイクルせず、次の更新が40%の安定した空き物理メモリで継続するまでサーバーが実行されます。
メモリが増え続けない場合、このメモリはコードに加えて、アプリケーション内で静的、const、文字列、および可能なキャッシュとして設定したデータです。
process Explorer を使用して、作業メモリと仮想サイズメモリを確認できます。
また、コードに対してプロファイルを実行して、「メモリリーク」などの問題があるかどうかを確認することもできます。グーグルから検索: https://www.google.com/search?hl=ja&q=asp.net+memory+profiler .
デバッガを使用する余裕がある場合の最善の方法は、 Windows Debugging Tools をインストールし、WinDbgやSOS.dllなどを使用して、メモリ内の内容を正確に把握することです。
ツールをインストールしたら、次のことができます。
その時点で、すべてのタイプをメモリ消費量の多い順にソートできるようになり、一番下のタイプから始められるようになります。 (通常は副作用であり、原因ではないため、文字列とオブジェクトを除外することをお勧めします)。 「!dumpheap -type type-here」を使用してインスタンスを見つけ、インスタンスに!gcrootを使用して、おそらく静的フィールド、またはイベントハンドラーのリーク、WCFチャネルの破棄などのためにメモリ内にある理由を見つけます。一般的なソースです。
おそらくここには当てはまりませんが、適切な方法でそれを投入すると思いました。最近、メモリの80%を実際にクリーンアップできたときに、メモリがすぐに最大になってしまうという問題がありました。問題:実際よりも2ギガほどギグが多いと考えたため、GCは非常に遅延していました。 (VMウェアのバグ-windowsは8 Gigを報告していましたが、物理的には6.4しかありませんでした)。ブログを参照してください。 http://www.worthalook.net/2014/01/give-back-memory /
役立つ可能性のあるもの:web.configを「書き換える」(開く/保存する)場合、アプリケーションはリセットされ、その時点からメモリ使用量を監視する必要があります。使用中に成長し続ける場合、これはメモリリークまたは異常なキャッシュを意味する可能性があります。サイト上のどのアクションがメモリの増加につながるかを特定できる場合があります。長い間、アプリケーションのメモリ使用量は安定しているはずです。