web-dev-qa-db-ja.com

w3wp.exeがメモリを大量に消費する

Small Business Server 2011のインストールでは、w3wp.exeプロセスの総数が不釣り合いな大量のメモリを使用しているように見えます。 SBSの標準インストールには、合計7つのサイトと20のASP.NETアプリケーションプール（Sharepoint、Exchange、WSUS、およびリモートWebワークプレースなどのSBS固有のもの）が付属しています。

結果として生じる数十のw3wp.exeプロセスは、時間の経過とともに4 GBを超えるサーバーのメモリを消費する傾向があり、ピークのアプリケーションプールはワーキングセットに約800 MBのWSUSに属するものです。 IIS MMCを介してアプリケーションプールを手動でリサイクルすると、一時的にメモリ使用量を減らすのに役立ちます（w3wp.exeプロセスは10 MBに縮小され、一部はすぐに再成長します）ですが、明らかに管理者が一日中やりたいことではありません。SBSがプリインストールされているアプリケーションプールの自動リサイクルに関する推奨事項を見つけることができなかったため、運用システムで「ただ実行する」ことに少し消極的です。

これを制限する方法についてのネットでの私の研究は、メモリが「他のアプリケーションで必要なときに解放される」ため、w3wpのメモリ消費は害を及ぼさないがパフォーマンスに利益をもたらすという多数の投稿を投げかけました。問題はそれがうまくいかないことです：

  • 1つは、SBSはマルチロールサーバーであり、その役割の1つ（主要な役割）はCIFSネットワークストレージです。これは、「他のどのプロセスでも使用されていない」のようにメモリが「フリー」であることに依存するファイルシステムキャッシュから非常にメリットを得ます。方法」-ユーザーをほとんど認識せず、メモリを消費するASP.NETアプリケーションプールは逆効果です
  • もう1つは、メモリ不足時にw3wpインスタンスのメモリ消費が大幅に減少することを確認する必要があることです。代わりに、100 mbを大幅に下回るわずかな減少と過度のスワッピングが発生し、パフォーマンスが低下しています。

IISまたはASP.NETアプリを管理することはほとんどないので、アプリケーションプールのメモリ要件を効果的に調整する方法についてのアイデアは大歓迎です。

iisasp.netapplication-poolswindows-sbs-2011
8
the-wabbit

これは私がやったことです：

web.config at %WINDIR%\Microsoft.NET\Framework\<version>\Configこの答え で提案されているとおり：

    <configuration>
      <system.web>
         <caching>
           <cache privateBytesLimit="5242880" privateBytesPollTime="00:01:00" />
         </caching>
      </system.web>
    </configuration>

これにより、デフォルトのプールリサイクル設定でメモリ使用量を1 GBをやや超える程度に減らすことができました。

どうやら、「サーバー」タイプのガベージコレクター（<gcServer = "true">） メモリを大量に消費する可能性があります も同様ですが、<gcServer>はデフォルトでfalseに設定されています。

7
the-wabbit

SBSのすばらしい世界へようこそ。 RAMの推奨要件は10 GBで、最低8 GBが必要です。 （ Microsoftによると 。）正当な理由があります。それは微調整のよく油を塗った機械ではありません...それは非常にずさんで肥大していて、太陽の下にすべてがまとめられています。あなたがそのボックスに投げ込めるRAMが多いほど...残念ながら、最大32GBに制限されています。どっちが……ばかげている。

7
TheCompWiz

結果のメモリ消費がソフトウェアの欠陥による問題であると思われる場合は、Microsoft DebugDiag 1.2を使用して、完全なメモリダンプを作成し、一般的な問題についてダンプを分析できます。メモリの問題があると思われる場合は、[リークの監視]オプションを選択してリーク追跡を有効にし、ダンプを作成/分析する前にしばらく実行する必要があります。

DebugDiag 1.2ダウンロード
https://www.Microsoft.com/download/en/details.aspx?id=26798

enter image description here

enter image description here

enter image description here

6
Greg Askew

すべてのアプリに個別のアプリプールは必要ありません。信頼できないアプリや優先したいアプリだけです。多くのユーザーが共有できます（異なる.netバージョンを個別に保持）。その後、アプリプールが使用するメモリをより現実的に制限できます。 1日に1回以上プールを繰り返しリサイクルする必要はありません。

また、この方法で解放できるメモリは非常に多くなります。一部はキャッシュされますが、各アプリには特定のWebアプリに大きく依存する一定量の作業メモリが必要です。これを過度に制限しようとすると、事態は深刻化します。

問題は、SBSが一度に多くのことを実行しようとすることです。実際に使用しているものを確認し、使用していないものをシャットダウンする必要があります。

しかし、たった11人のユーザーに正直に言うと、残りのメモリはどこに行くのでしょうか。軽い使用のための交換とSQLは確かにありません必要 12Gb以上！

2
JamesRyan