VirtualLockWinAPI 呼び出しの目的は、ページをプロセスのワーキング セットにロックすることです。ただし、WorkingSet64不可解なことに、API はそれらのページをカウントしません。
おそらくこの結果として、プロセス エクスプローラーも標準のタスク マネージャーも、プロセスごとのメモリ使用量統計でロックされたページをカウントしません。
これどうしたの？WinNT の仮想メモリに精通している誰かが、この不一致に光を当てることができますか?この不一致により、使用されている数ギガバイトの RAM が本質的に検出されない可能性があります。(SQL Server または VirtualBox を考えてください)
ああ、それは簡単に説明できます: 間違った API を使用しています。GetProcessWorkingSetSize は、ワーキング セットの最小サイズと最大サイズを照会します。これらはクォータであり、実際の値ではありません。
ワーキング セットの最小サイズは、世界が終わらない限り Windows が RAM にロックし続けることを保証するサイズです。ワーキング セットの最大サイズは、ページがプールに移動される前に Windows がプロセスに許可するメモリの量です (それらは必ずしもなくなるわけではありませんが、それらにアクセスするとエラーが発生し、再マッピングが発生します)。
EDIT :
間違った API を使用していないことが明らかになったので (間違った func という名前のみ) 、XP システムでいくつかのテスト (VirtualAllocおよびメモリ マップ ファイルを組み合わせて実行) を行いました。VirtualLock一見、あなたが完全に正しいように見えました。650MB のファイルから 512MB を割り当てるか、メモリ マッピング 512MB を実行すると、仮想サイズに 512MB が追加されましたが、ワーキング セットは増加しませんでした。a をVirtualLock(512MB)続けても、ワーキング セットにはまったく影響しませんでした。
次にVirtualLock、すべてのケースでまったく時間がかからなかったことに気付きました。たとえば、ディスクから 0.5 ギガバイトをフェッチする必要があるなど、もっともらしいとは思えませんでした。それで、私は戻りコードをチェックして、何を推測しました。Windows は 512MB をロックすることは良い考えではないと考えており、それを拒否します。
わずか 64MB で実験を繰り返したところ、ワーキング セットはすぐに 64MB 増加しました。つまり、一言で言えば、「私のために働く」ということです。
念のため、リターン コードを確認しましたか?
よく見ると、この動作は明確に定義され、十分に文書化されています。VirtualLock明示的に述べるドキュメント:
プロセスがロックできるページの最大数は、その最小ワーキング セット内のページ数からわずかなオーバーヘッドを差し引いたものに等しくなります。
ロックの有無にかかわらず、WS クォータを適切に設定した後:
VirtualBox は別の問題です。タスク マネージャーに表示されるのは、「インターフェイス」プログラムと「マネージャー」フロントエンドのワーキング セットのみであり、どちらも常に 64M 未満のワーキング セット サイズを維持しています。一部のドライバーでどのメモリが割り当てられているのか、またはメモリがまったくロックされているのかどうかはわかりませんが。
現在、それぞれ 1.6 GB のメイン メモリを搭載した 2 つの仮想マシンを実行しています。私の 32 ビット Windows が 3.25GB しか認識していないことを確認すると、VM に属するメモリがロックされている場合は、わずか 50MB しか残りません。その上、Process Explorer は、Firefox だけで 474MB のワーキング セットがあり、これを入力している間に増加していることを教えてくれます (聖なる...?!!)。仮想マシン内のすべてのメモリが実際にロックされているとは限りません。そのような数値は完全に不可能だからです。
リクエストに応じて、VMMap のショットを次に示します。
数字は確かにおかしいです... VM には合計 1.6M があり、VMMap によると、821MiB が予約され、772MiB がコミットされています。Process Explorer には、それぞれ 163MiB と 54MiB しか表示されません。そこには明らかに怪しいものがありますが、これはおそらく Windows の問題ではなく、あいまいな VirtualBox ハッカーであると思われます。