私はIIS 6サーバーでWindows 2003 SP2 x86を実行しています。サーバーには4GBのRAMがあり、割り当てられた2GBで一貫して実行されます。
X86では、サーバーが4GBのすべてを利用するわけではないことを認識していますRAMおよびアプリケーションスペースも制限されていますが、IISプロセスは制限されているようです他の場所。w3wp.exeには500MBを超える割り当てがなく、ビジーな.NETアプリケーションからOutOfMemory例外が発生することがあります(複数のアプリケーションが実行されており、それぞれに個別のアプリケーションプールがあります)。
IIS6 Webサイト/アプリプールが使用できる最大メモリはどれくらいですか?
Windows x86でのアプリは2GB/EAに制限されています。これを変更するには、boot.iniに/ 3gbフラグを追加しますが、これによりアプリケーションが予期しない動作をする可能性があるため、注意して使用する必要があります。 MSはこれを正式にサポートしていません( http://technet.Microsoft.com/en-us/library/bb124810.aspx )
IISのメモリ制限は、関連するアプリプールの[リサイクル]タブで設定できます。
アプリケーションが500MBを超えないことをどのように判断していますか?タスクマネージャを使用している場合は、Windowsが理解しているように、メモリ使用量を正確に表すことはほとんどありません(あるとしても)。プロセスエクスプローラーを使用: http://technet.Microsoft.com/en-us/sysinternals/bb896653.aspx
他にも多くの関連する質問があります:
ほとんどの場合、IIS、ASP.NET、およびそれらに関連するすべての手荷物は、Windowsタスクマネージャーに表示されていなくても、2 GBの制限に達しています。リサイクルの制限を設定するか、x64にアップグレードすると、おそらく大きな違いが生じます。
忙しい.NETアプリケーションからOutOfMemory例外を受け取ることがある
これに対する答えは複雑すぎて答えに収まりません。主題の完全な扱いについては、 " 。NETアプリケーションのパフォーマンスのチューニング "を参照してください。
これは Bruno Jouhier からの非常に単純化された(しかしそれでもかなり良い)要約です。
さらに、.NETランタイムでは、最大2 GBにできません。ガベージコレクターはライブオブジェクトをコピーすることで機能するため、コピーを実行するにはかなりの容量が必要です。
これが私の説明の試みです...
X86上のASP.NETワーカープロセスの(タスクマネージャーによって報告された)最大ワーカープロセスメモリサイズが何であるか疑問に思っている場合、答えは "それは依存する"。
Javaまたは.NETなど)のマネージコードでは、プログラマーはポインターを処理する必要がないため、メモリの細かい制御をやめさせます。プログラムを実行すると、ヒープスタックは ガベージコレクター によって定期的にクリーンアップされます。
特にASP.NETに関しては、ガベージコレクターはWebサイトと同じワーカープロセス内で実行されます。 GCはそれ自体のメモリを消費します。どのようにmuchメモリは、完全にアプリケーションのコードがどのように記述されるかによって決まります。 1つのアプリが1.8GBのメモリを使用できる一方で、別のアプリは500MBで窒息する場合があります。 理由を理解するには、特定のアプリケーションのプロファイルを作成する必要があります。
X86 Windows OS上のプロセスは、boot.iniファイルで/ 3gbスイッチを設定していない限り2gbに制限されています。この場合、プロセスは3gbを使用できます。
アプリプールに仮想メモリサイズを設定していないことを確認してください。この値を許容範囲外の数値に設定すると、512MBに戻ります。 KB923197 を参照してください。
また、ASP.Netアプリケーションを実行している場合、ASP.Netは2GBのメモリ制限の60%、つまり1.2 GBでプールをリサイクルします。これは500シナリオではありませんが、メモリを大量に使用する32ビットのアプリケーションプールでは、メモリを少し増やすためにこれを週に1回行う場合があります。
<system.web>
<processModel memoryLimit="80" />
</system.web>
このブログ投稿から "SharePointアプリケーションプール設定の推奨事項" :
物理に焦点を当てます。通常、メモリの数と量に応じてアプリプールがほとんどない32ビットアプリでは、アプリプールを最大800 MBから1200 MB程度に制限します。 2 GBのサーバーではRAM約800MBに設定します。4GBのRAMサーバーが約1GBで、最大でさらに多くの場合1200前後。8〜16 GBのメモリを搭載した64ビットのWebフロントエンドでは、2 GBのRAMの設定、またはそれを制限するのではなく、許可することさえ可能だと聞いたことがあります。
これらは実際に処理してキャッシュするまで大きくなる可能性があるため、実際にプロファイルする必要があります。メモリの量と負荷が大きいほど、ワーカープロセスが大きくなります。人々がアプリプールの設定について尋ねるとき、これは彼らが通常何が何であるべきかを尋ねているところです。ここで行っていることは、アプリプールがより多くのメモリを消費することを明示的に制限しています。この設定は[リサイクル]タブにありますが、それには理由があります。
アプリプールが最大値に達すると、最大プロセッサ設定とは異なります。小さな再起動やiisresetに似たワーカープロセスを循環させますが、メモリを解放するためにこれを実行したい場合があるためです。理想的な世界では、24時間に2、3回以上サイクルする必要はありません。朝のピークが発生する直前に循環して、利用可能なメモリが最大になるようにしようとする人や、バックアップまたはクロールが始まる前の1日の終わりに循環することを聞いたことがあります。
私の経験から800 MBは32ビットマシン(2-4 GB RAM)のしきい値です。 「メモリ不足」例外をスローする前に、アプリプールをリサイクルします。
Windows 2003では、 Physical Allocation Extension (PAE)を設定して、すべてのメモリを利用できます。 IIS6アプリプールのデフォルトメモリは 5MB です。