Process Explorerを使用して、一部のデータを再構築している間にWindowsサーバーを監視しています。これは主にCPUを集中的に使用するプロセスですが、スワッピングではないことを確認したいと思います。Process Explorerを使用しているかどうかを確認するにはどうすればよいですか？私の最初の推測は「システム情報」ウィンドウにあり、それはページングファイル書き込みデルタです。はい？いや？私はアホです？
*スクリーンショットはサーバーのものではありません...単なる例です。
代替テキストhttp://www.malwareinfo.org/bootcamp/img/ProcessExplorer2.jpg
回答:
「Pages Input / secは監視するカウンターですが、* nixesのようにウィンドウはページファイルを使用しないため、「スワップ」を心配する必要はありません。
最初に、Windowsページが出ないことを理解する必要があります。Eric Lippertsのブログ投稿の関連部分（軽く編集）を引用します。
「RAMは単なるパフォーマンスの最適化とみなすことができます。RAMのデータへのアクセスは、光の速度に近い電界で情報が保存されるため、情報が膨大で重い場所に保存されるディスク上のデータにアクセスするよりもはるかに高速です非鉄金属分子
オペレーティングシステムは、どのプロセスから最も頻繁にアクセスされているストレージのページを追跡し、RAMにコピーを作成して、速度を向上させます。プロセスが現在RAMにキャッシュされていないページに対応するポインターにアクセスすると、オペレーティングシステムは「ページフォールト」を実行し、ディスクに出て、ディスクからRAMにページのコピーを作成します。近いうちに再びアクセスされることになるでしょう。
オペレーティングシステムは、読み取り専用リソースの共有についても非常に賢明です。2つのプロセスが両方とも同じDLLから同じコードのページをロードする場合、オペレーティングシステムは2つのプロセス間でRAMキャッシュを共有できます。コードはおそらくどちらのプロセスでも変更されないため、RAMの重複ページを共有して保存することは完全に賢明です。
しかし、巧妙な共有を使用しても、最終的にこのキャッシングシステムはRAMを使い果たしてしまいます。その場合、オペレーティングシステムは、すぐに再びアクセスされる可能性が最も低いページを推測し、変更された場合はディスクに書き込み、そのRAMを解放して、再びアクセスされる可能性が高いものを読み取ります。すぐに。
オペレーティングシステムが誤って推測した場合、またはより多くの場合、実行中のすべてのプロセスで頻繁にアクセスされるすべてのページを格納するのに十分なRAMがない場合、マシンは「スラッシング」を開始します。オペレーティングシステムは、高価なディスクストレージの書き込みと読み取りにすべての時間を費やし、ディスクは常に実行され、作業は行われません。
これは、「RAMを使い果たす」という結果が「メモリ不足」エラーになることはほとんどないことも意味します。エラーの代わりに、ストレージが実際にディスク上にあるという事実の全コストが突然重要になるため、パフォーマンスが低下します。
これを見るもう1つの方法は、プログラムが消費する仮想メモリの総量は、実際にはそのパフォーマンスにあまり関係がないということです。関連するのは、消費される仮想メモリの総量ではなく、（1）そのメモリのどれだけが他のプロセスと共有されていないか、（2）よく使用されるページの「ワーキングセット」の大きさ、 3）すべてのアクティブなプロセスのワーキングセットが使用可能なRAMより大きいかどうか。
これで、「メモリ不足」エラーが、通常、使用している物理メモリの量や、使用可能なストレージの量とは何の関係もないのは明らかです。ほとんどの場合、アドレス空間は32ビットWindowsでは比較的小さく、簡単に断片化されます。」
いくつかの追加ポイント：
Windowsでのメモリ管理の仕組みの全体像については
メモリの問題があると思われる場合は、まずWindowsメモリのトラブルシューティングに関するこのプレゼンテーションを見ることをお勧めします
メモリの断片化のおかげではないのに、時々「メモリ不足」になることがある理由を説明します。
Windowsの限界に挑む：物理メモリも参照してください。
RAM、仮想メモリ、ページファイルなどすべて（Microsoftサポート）
更新：
Windows 10はメモリで少し異なることを行い、時間が経つにつれて「システムと圧縮メモリ」というプロセスが表示されます。Windows10はページングリストに「圧縮ストア」を追加します。このRAMは、システムが所有するUSERメモリです（通常、システムにはカーネルメモリしかありません）。このメモリは、平均で約30％削減されるように圧縮されています。これにより、より多くのページをメモリに保存できます（70％以上のスペースを使用する計算を実行している場合）。メモリにまだ圧力がある場合は、圧縮ストア（ユーザーモードのシステムプロセススペース）からのページを変更済みの物理ページファイルに書き込むことができるリスト（圧縮済み）。システムは、それらがシステムユーザーモードスペースからのものであり、圧縮されていることを確認し、ストアに戻そうとしません。したがって、Windows 10システムでは、システムがramを吸入しているように見えるかもしれませんが、実際には、ramをより効率的に使用しようとしています。Macユーザーは2013年から同様の機能を使用しており、新しいバージョンのLinuxカーネルはメモリ圧縮のバージョンを採用しています。メモリを節約するこの方法は、優れているだけでなく、他のオペレーティングシステム間でも既に一般的です。
はい、ページングデルタは、サーバーがどのくらいページング（または「スワップ」）しているかをライブで示しますが、その時点でのみです。これをより詳しく見て、履歴ビューを見るには、パフォーマンスモニター（perfmon.exe）を使用して、これらのデルタ（および特定のイベントまたはアクティビティをスパイクと相関させるのに役立つ可能性のあるその他のパフォーマンスカウンターをグラフ化または記録することをお勧めしますページングアクティビティ）。
ここではパフォーマンスモニター（perfmon）があなたの友達です。ハードページフォールト（つまり、要求を満たすために必要なメモリページをディスクから読み取る必要がある場合のページフォールト）を探しているため、ハードページフォールトとソフトページフォールトの両方を監視するのは最適ではありません。
perfmonを使用して「メモリ」オブジェクトの「ページ入力/秒」カウンタを監視し、発生しているハードページフォールトの数を把握します。
良い経験則は、コミットチャージが物理メモリよりも高い場合、間違いなく何かをページングしますが、アプリが常に使用中の単一の固定データバッファーを使用する場合、通常はページングされませんまったく。他のメモリをページアウトして、このためのスペースを確保する間、起動時に多少の遅延が発生する場合があります。