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アプリを管理することはほとんどないので、アプリケーションプールのメモリ要件を効果的に調整する方法についてのアイデアは大歓迎です。

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

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

この回答で提案さweb.configれ%WINDIR%\Microsoft.NET\Framework\<version>\ConfigているようにatでprivateBytesLimitパラメータを設定して、.NET AppPoolsのサーバーアプリケーションキャッシュを低い値（5 MB）に設定します。

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

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

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

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

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

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

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

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

しかし、たった11人のユーザーに正直に言うと、残りのメモリはどこに行くのでしょうか。ExchangeとSQLを使用すると、12Gbを超える必要はありません。