11

タイトルが示すように、ページ ファイルのアクティビティが多いという問題があります。

ハードドライブからロードする多くの画像を処理するプログラムを開発しています。すべての画像からいくつかのデータが生成され、リストに保存されます。3600 枚の画像ごとにリストをハード ドライブに保存します。そのサイズは約 5 ～ 10 MB です。可能な限り高速に実行されるため、1 つの CPU スレッドが最大になります。

プログラムは動作し、想定されているデータを生成しますが、Visual Studio で分析すると、「DA0014: Extremely high rate of paging active memory to disk 」という警告が表示されます。

タスク マネージャーによると、プログラムのメモリ消費量は約 50 MB で、安定しているようです。プログラムを実行したとき、4 GB のうち約 2 GB が残っていたので、RAM が不足しているとは思えません。 プログラムのメモリ使用量http://i.stack.imgur.com/TDAB0.png

DA0014 ルールの説明には、「たとえば、1 秒あたりのページ出力数は、1 秒あたりのページ書き込み数よりもはるかに大きいことがよくあります。1 秒あたりのページ出力数には、システム ファイル キャッシュから変更されたデータ ページも含まれているためです。ただし、そうではありません。どのプロセスがページングの直接の原因であるか、またはその理由を常に簡単に判断できます。」

これは単にハード ドライブから多くの画像を読み取ったためにこの警告が表示されるということですか、それとも別の理由でしょうか? 私が探しているバグの種類がよくわかりません。

編集：挿入された画像へのリンク。

EDIT1: 画像サイズはそれぞれ約 300 KB です。次をロードする前に、それぞれを破棄します。

更新:実験から、大量のファイルをロードするだけでページングが発生するように見えます。私は C# や基礎となる GDI+ API の専門家ではないので、どの回答が最も正しいかわかりません。私は Andras Zoltans の回答を選びました。なぜなら、それはよく説明されていたからです。また、彼は私のような初心者に理由を説明するために多くの作業を行ったようです:)

4

2 に答える 2

4

次の詳細情報を更新

アプリケーションのワーキング セットはそれほど大きくないかもしれませんが、仮想メモリのサイズはどうでしょうか。ページングは​​、物理的なサイズだけでなく、このために発生する可能性があります。Windows 8 で実行されている VS2012 のProcess Explorerからのこのスクリーン ショットを参照してください。

VS 2012 メモリ

そしてタスクマネージャーで？どうやら、同じプロセスのプライベート ワーキング セットは 305,376Kb です。

このことから、a) タスク マネージャーは必ずしも信頼できるとは限らないこと、b) OS に関する限り、メモリ内のアプリケーションのサイズは、私たちが考えているよりもはるかに複雑であることがわかります。

あなたはこれを見てみたいかもしれません。

ページングは​​、ほぼ確実にファイルの処理が原因であり、最終的な数値が高いのは、作業しているファイルの数が原因であることがほぼ確実です。その簡単なテストは、さまざまな数のファイルで実験し、それらと一緒に最終的なページング数値のデータセットを生成することです. ファイルの数がページングの原因である場合、明確な相関関係が見られます。

次に、行った処理をすべて削除し (ただし、画像の読み込みは維持します)、再度比較します。違いに注意してください。

次に、画像読み込みコードを完全にスタブします。違いに注意してください。

明らかに、画像の読み込みを取り除くと、障害が最大に減少することがわかります。

ここで、Emgu.CV Image codeを見ると、クラスを内部的に使用しImageて画像ビットを取得します。つまり、関数 GdipLoadImageFromFile (このインデックスの 2 番目のエントリ)を介して GDI+ を起動し、画像をデコードします (システム リソースを使用し、さらに潜在的に大きなバイト配列) - 次に、実際の RGB 値を含む圧縮されていないバイト配列にデータをコピーします。

GCHandle.Allocこのバイト配列は( と で囲まれGC.AddMemoryPressureている) を使用して割り当てられGC.RemoveMemoryPressure、固定されたバイト配列を作成してイメージ データ (非圧縮) を保持します。現在、私は .Net メモリ管理の専門家ではありませんが、各ファイルが並列ではなく順次ロードされたとしても、ヒープの断片化の可能性があるように思えます。

それがハードページングの原因かどうかはわかりません。しかし、それは可能性が高いようです。

特に、イメージのメモリ内表現は、元のファイル バイトではなく、表示に特化したものにすることができます。したがって、たとえば JPEG について話している場合、300Kb の JPEG は、そのサイズにもよりますが、物理メモリでかなり大きくなる可能性があります。たとえば、1027x768 の 32 ビット イメージは 3Mb です。これは、イメージがロードされ (最初の割り当て)、EMGU イメージ オブジェクトにコピー (2 回目の割り当て) されてから破棄されるため、各イメージに2 回割り当てられています。

しかし、問題を回避する方法を見つける必要があるかどうかを自問する必要があります。アプリケーションが大量の物理 RAM を消費していない場合、他のアプリケーションへの影響ははるかに少なくなります。十分な物理メモリがあれば、あるプロセスが何度もページ ファイルにヒットしても、ヒットしない別のプロセスに悪影響を与えることはありません。

于 2012-12-07T09:32:58.510 に答える
1

ただし、どのプロセスがページングの直接の原因であるか、またはその理由を特定することは必ずしも容易ではありません。

悪魔はその警官のメモにいます。ビットマップは、メモリ マップ ファイルを使用して、ピクセル データを含むファイルからメモリにマップされます。これは、RAM との間で直接データを読み書きすることを避ける効率的な方法です。料金は使用した分だけです。ファイルを RAM と同期させるメカニズムは、ページングです。そのため、大量の画像を処理すると、多くのページ フォールトが発生することは避けられません。使用するツールは、これが設計によるものであることを認識できるほど賢くありません。

機能であり、バグではありません。

于 2012-12-07T14:31:59.393 に答える