メモリがいっぱいになる前にWindows 2008がスワップを使用するのはなぜですか？

私は、IISと.NET4 Webアプリを実行しているWindows 2008サーバー（Amazon EC2上）を管理しています。先日、メモリアラートを受け取って行って見ましたが、ある種の遅いリークによって、プロセスメモリが時間の経過とともに増大していたことは確かです。それは60Mから200Mのように、それほど大きくはなりませんでしたが、かなり低いしきい値（75％）を超えてモニターをオフに設定するのに十分なほど、ボックスが続いていました。

アプリのプールとメモリが解放されてリサイクルしたところ、統計を確認したところ、スワップスペースが大幅に使用されており、そのリサイクルで1 GBを超えるメモリが解放されたことがわかりました。

多分これは基本的な質問かもしれませんが、私はUNIXの男で、メモリ不足になるまでスワップに慣れずに慣れています。このボックスは、メモリ使用量が75％を超えたことはありません。これはWindowsのものか、.NETのものか、Amazonのものですか？このアプリには、想定よりもはるかに大きなメモリリークがあると思います。60Mから200Mにリークしておらず、60Mから1.2GBにリークしていますが、その多くは、「コールド」になり、スワップにプッシュされていますか？

アプリケーションプールにメモリリサイクルが設定されていますが、オフボックスのフルメモリがトリガーされるため、このアプリは自動的にリサイクルされる前に非常に大きくなる可能性があります。

定期的な「時間指定」リサイクルを設定することもできましたが、これは回避策です。開発者にアプリを修正してもらいますが、スワップの使用法でここで何が起こっているのかを理解して、この権利を確実に理解する必要があります。

詳細情報で編集：インスタンスメモリ：1.7 GBスワップ：4.5 GB

taskmgrのw3wp.exeプロセスで、メモリが211,000kであることがわかります。しかし、それを再起動すると（独自のアプリプールにあり、ボックス上の唯一のアプリです）、メモリ使用量は通常の開始点である60Mまで下がり、1 GB以上のスワップも解放されました。taskmgrでは、通常のメモリ（プライベートワーキングセット）の統計を表示しましたが、他の監視（Cloudkick）でスワップの変化を確認しました。さかのぼって、今日見てみると、メモリはプロセスで195M（合計1.2 GB）に戻っており、スワップは1.0 GBから1.1 GBに急増しています。遅いクリープ）。

私はこの特定のアプリについてはそれほど心配せず、Windowsがいつスワップし、それがどのように使用されるかを理解すること、および特定のWindowsメモリとスワップの一般的な使用について何を心配するべきかについてもっと心配しています。

WindowsとLinuxには、2つの異なるページ/スワップ戦略があります。

Linux

Linuxは、スワップ領域の使用をまったく避けたいと考えており、可能な最後の瞬間まで待機します。Linuxで大量のスワップが見られる場合は、システムに問題があるか、問題があった可能性があります。この戦略は、システムの最も遅い部分であるディスクI / O全体を最小限に抑えるのに適していますが、軽負荷と重負荷が交互に繰り返されるシステムでは弱くなります（正直なところ、それが私たちのほとんどです）。負荷がすでに重いときは、「追加の」ディスクI / Oによって負荷がかかるようになります。つまり、別の言い方をすると、サーバービルドを設計するときに、スワップ中にもスワップしない十分なRAMを確保する必要があります。予想される最大の読み込み時間。

ウィンドウズ

Windowsは、メモリをページファイルの単なるキャッシュとして扱いたいと考えています。あなたの本当のメモリは、ディスク上に常にあるが、それは最初にそれができるならば、「キャッシュ」から読み取り/書き込みます。この戦略は、時間の経過とともに負荷を均等にするのに適しています。システムがビジー状態になり、ページをスワップする必要がある場合、現在のページはすでにディスク上にあり、作業の半分はすでに行われています。このアプローチは、Windowsが若い頃には非常に理にかなっており、32 MB（GBを忘れて）はまだ大量のRAMであり、スワップスペースを頻繁に使用する必要性がありました。今日でも、これは、時間の経過とともにディスクI / Oをより均等に分散させるのに役立つので、負荷が軽い負荷と負荷が高い負荷の間で切り替わる作業負荷に適しています。

最新のWindowsバージョンには、SuperFetchなどの追加の最適化があり、負荷が軽いときにディスクおよびRAMにメモリページをプリロードして準備し、プログラムを初めてロードするときに追加のディスク書き込みの必要性を回避します。つまり、予想される最高の負荷よりも少ないデータに対して十分なRAMを必要とするようにシステムを設計できるため、コストを削減しながら、常に少なくとも許容可能なパフォーマンスを維持できます。

収束

最初にテスト環境で負荷を測定または予測し、次に負荷がわかっているときに本番リソースを割り当てるというこの概念は、システム構築における比較的最近の開発であり、一部は仮想サーバー、次にクラウドサーバーの登場により実現しました。 。負荷によっては、まったくスワップする必要がないようにシステムを設計することもできます。このような場合、Windowsではページングをオフにして、Linuxシステムのように動作させることができます。ただし、注意が必要です。システム設計が予想よりも多くのメモリを必要とする場合、この方法で問題が発生する可能性があります。

一方、最近のLinuxカーネルは、以前よりも便宜的にディスクにスワップすることをいといません。したがって、2つのシステム間でのメモリ管理戦略の違いは依然として存在しますが、今では以前ほど明確ではありません。どちらのシステムにもメリットがあり、それぞれが他方を監視して、コピーできる進歩を確認します。

Windows（およびLinuxと他のUnix-aのようなOS）は、しばらく使用されていないページをディスクに移動して、バッファーとキャッシュのためのスペースを作り、アクティブなI / Oアクティビティを高速化します。また、アプリケーションは、すぐに使用するよりも多くのメモリを割り当てることがよくあります。これにより、カーネルがバックグラウンドで最近変更されていないものをページングし、突然起動したときにページングの遅延が発生しないようにすることができます。その割り当てを使用します。

Linuxでは、/procファイルシステムの関連する「スワップ」値を変更することで、この動作を微調整（またはブロック）できます。この点に関してWindowsの動作を変更するために微調整できるレジストリ値があることは間違いありません。

もう1つ注意すべき点は、何かがページアウトされ、後で読み戻された場合、ファイルがいっぱいになるか、RAMのページが変更されるまで、カーネルはページファイルから削除しないことです。この方法では、そのチャンクを再度ページングする必要がある場合、実際にページをディスクに書き込む必要なしにページングできます。コンテンツはすでにそこにあります。これにより、メモリのオーバーコミットが悪化してページファイルのスラッシングが発生するような状況でのパフォーマンスが大幅に向上します（かなりの数のページが絶えずマップされたりマップされたりします）。そのメモリリークによって一部のデータが押し出されたため、これらのページを後でマップする必要がある場合、またはRAMをRAMに再配置する必要がある場合に備えて、ディスクからワイプされていないことがわかります。Linuxでは、「SwapCached」の値は/proc/meminfoは、RAMとディスクに同じコピーを持つページに存在するデータの量を示しています。Windowsは間違いなく同じ最適化（または類似の何か）を使用しますが、これがどの程度発生しているかを確認するためにどこを探すべきかは正確ではありません（クエリできる関連するパフォーマンスモニターカウンターがあることは間違いありません）。

tl; dr：これは正常です。最新のOSカーネルは、I / O操作を保存するためにキャッシュとして使用できるRAMを最大限に活用し、賢くしようとします。また、これらのビットをページアウトする必要がある場合、I / Oを保存するためにデータをディスクおよびRAMにコピーすることがあります。後でRAMの。おそらく直感に反して、これらの2つの方法でのページファイルの使用は、現在RAMが少なくない場合でも、全体のパフォーマンスを低下させるのではなく向上させる可能性があります。