1. ホーム
  2. debugging

[解決済み] プライベートバイト、バーチャルバイト、ワーキングセットとは?

2022-02-08 13:06:59

質問

Windowsユーティリティのperfmonを使用して、プロセスのメモリリークをデバッグしようとしています。

perfmonはこのように用語を説明しています。

ワーキングセット は、このプロセスのワーキングセットの現在のサイズ (バイト単位) です。作業セットは、プロセス内のスレッドによって最近タッチされたメモリページのセットです。コンピュータの空きメモリが閾値を超えている場合、ページは使用されていなくてもプロセスのワーキングセットに残されます。 空きメモリが閾値を下回ると、Working Setからページが切り捨てられる。必要な場合は、メインメモリーを離れる前にワーキングセットにソフトフォールトバックされます。

仮想バイト は、そのプロセスが使用している仮想アドレス空間の現在のサイズ (バイト単位) を表します。仮想アドレス空間の使用は、必ずしもディスクやメインメモリページの対応する使用を意味するものではありません。仮想空間は有限であり、プロセスはライブラリのロードを制限することができます。

プライベートバイト は、このプロセスが割り当てた、他のプロセスと共有できないメモリの現在のサイズ (バイト単位) です。

以上が私の質問です。

プロセスが共有ライブラリを使用せず、リークが発生した場合、プロセス自体から発生するため、リークが発生しているかどうかを確認するために測定すべきなのはプライベートバイトでしょうか?

プロセスで消費される総メモリ量はどのくらいですか?Virtual Bytesでしょうか、それともVirtual BytesとWorking Setの合計でしょうか?

Private Bytes、Working Set、Virtual Bytesの間には何か関係があるのでしょうか?

メモリ使用量を知ることができる他のツールはありますか?

解決方法は?

この質問に対する簡単な回答は これらの値はいずれも、実行ファイルが実際に使用しているメモリ量の信頼できる指標ではなく、メモリリークのデバッグにはあまり適していません。

プライベートバイト プロセスの実行ファイルが持っているメモリ量を指す 要求する - 必ずしも 実際に使用する . これらは、(通常)メモリ マップされたファイル(すなわち共有 DLL)を除外するため、quot;private" です。 しかし、ここで注意が必要なのは、必ずしもメモリを除外するとは限らないということです。 これらのファイルによって割り当てられた . プライベートバイトの変化が実行ファイル自身によるものなのか、リンクされたライブラリによるものなのかを見分ける方法はありません。 また、プライベート・バイトは ではなく ディスクにページングされるか、待機ページリスト (つまり、もう使用されていないが、まだページングされていない状態) になります。

ワーキングセット とは、合計 物理的 が使用するメモリ(RAM)のこと。 ただし、プライベートバイトとは異なり、メモリマップドファイルやその他様々なリソースも含まれるため、プライベートバイトよりもさらに精度の低い測定値となります。 これは、タスクマネージャの "Mem Usage" で報告される値と同じであり、近年では無限の混乱の原因となっています。 ワーキング セット内のメモリは、ページフォルトなしでアドレス指定できるという意味で、quot;physical" ですが、スタンバイ ページ リストは次のとおりです。 また このため、アプリケーションを最小化したときに "Mem Usage" が突然低下するのを見ることがあります。

仮想バイト数 は、合計 仮想アドレス空間 プロセス全体によって占有されます。 これは、メモリマップドファイル(共有DLL)を含むという意味ではワーキングセットと同じですが、スタンバイリスト内のデータや、すでにページアウトされてディスク上のどこかのページファイルに眠っているデータも含まれます。 高負荷状態のシステムで各プロセスが使用する仮想バイトの合計は、マシンが実際に持っているメモリよりもかなり多くなります。

ということは、人間関係は

  • Private Bytesは、アプリが実際に割り当てたものですが、ページファイルの使用量も含まれます。
  • Working Setは、ページングされていないPrivate Bytesと、メモリマップドファイルの合計です。
  • 仮想バイトは、ワーキングセットにページングされたプライベートバイトとスタンバイリストを加えたものです。

共有ライブラリは、アプリケーションモジュール内でメモリを割り当てることができるため、アプリケーションのプライベートバイトに誤検出が報告される可能性があるのと同じです。 あなたの アプリケーションの内部でメモリが割り当てられる可能性があります。 共有 モジュールで、偽の ネガティヴ . つまり、プライベートバイトに全く現れないメモリリークが、アプリケーションに存在する可能性があるということです。 ありえないことですが、可能性はあります。

プライベートバイトは合理的な 近似値 実行ファイルが使用しているメモリ量の目安になり 絞り込み メモリリーク候補のリストを作成し、その数がどんどん増えていくようであれば、そのプロセスをリークしていないかチェックしたくなるはずです。 しかし、これはできない。 証明する リークがある、ないにかかわらず

Windowsのメモリリークを検出/修正するための最も効果的なツールの1つは、実は ビジュアルスタジオ (リンク先は製品ページではなく、VSのメモリリーク対策に関するページです) 。 ラショナルピュリファイ も可能性があります。 また、マイクロソフトはより一般的な ベストプラクティス文書 というテーマで、この問題を取り上げます。 このページには、さらに多くのツールが掲載されています。 前の質問 .

これで少しはスッキリしたかな!? メモリリークの追跡は、デバッグの中でも最も難しいことの一つです。 がんばってください。