2

私は 2GB の RAM を持っており、メモリを集中的に使用するアプリケーションを実行していて、使用可能な物理メモリが少ない状態になり、アプリケーションやメニューの呼び出しなどを開くなどのユーザー アクションにシステムが応答しません。

メモリをページファイルにスワップして物理メモリを解放するようにシステムにトリガーまたは指示するにはどうすればよいですか? Windows XP を使用しています。

同じアプリケーションを 4GB RAM のマシンで実行すると、そうではなく、システムの応答は良好です。利用可能な物理メモリがいっぱいになった後、システムは自動的にページファイルにスワップし、物理メモリを解放しますが、2GB システムほど悪くはありません。

この問題を克服するために (2GB マシンで)、アプリケーションによって割り当てられる大きなデータセットにメモリ マップ ファイルを使用しようとしました。この場合、アプリケーション (プロセス) の仮想メモリは問題ありませんが、システム キャッシュが高く、物理メモリが少ないという上記と同じ問題があります。

メモリ マップ ファイルがプロセス仮想メモリ システム キャッシュにマップされていないにもかかわらず、キャッシュが高くなっています。どうして？？？！！！:(

どんな助けでも大歓迎です。ありがとう。

4

3 に答える 3

1

メモリマップトファイルを使用するためのデータアクセスパターンがシーケンシャルである場合、基になるファイルを開くときにFILE_FLAG_SEQUENTIAL_SCANフラグを指定することで、ページのリサイクルが少し改善される可能性があります。データパターンがマップされたファイルにランダムな順序でアクセスする場合、これは役に立ちません。

マップビューのサイズを小さくすることを検討する必要があります。ここで、すべてのメモリが実際に消費され、キャッシュされます。使用可能な連続した空き物理メモリよりも大きいファイルを処理する必要があるように思われるため、仮想メモリよりもメモリの使用方法をよく知っているので、仮想メモリページスワッパーよりも優れたメモリ管理を行うことができます。メモリマネージャはそうします。可能であれば、小さいビューを使用して大きいファイルの一部を操作できるように、デザインを調整してみてください。

基になるファイルの全範囲にわたる完全なランダムアクセスの必要性を取り除くことができない場合でも、必要に応じてビューを破棄して再作成し、ビューをファイルのセクションに移動することが有益な場合があります。次の操作にアクセスする必要があります。データアクセスパターンが先に進む前にファイルの一部に集中する傾向がある場合は、ビューを頻繁に移動する必要はありません。ビューオブジェクトを破棄して再作成するためにヒットしますが、ビューを破棄すると、ビューに関連付けられているすべてのキャッシュページも解放されるため、ビューが小さいほどパフォーマンスが大幅に低下するため、パフォーマンスが大幅に向上する可能性があります。システム全体のメモリ不足とページスワッピング。インストールされているシステムRAMの一部に基づいてビューのサイズを設定し、ファイル処理の必要に応じてビューを移動してみてください。ビューが大きいほど、移動する必要は少なくなりますが、RAMの消費量が増えるため、システムの応答性に影響を与える可能性があります。

于 2010-05-12T00:50:50.703 に答える
1

投稿で示唆しているように、応答時間が遅いのは、OS がメモリの内容をページファイルに書き込んで物理メモリ内の他のプロセスのためのスペースを確保している間のシステムの遅延が少なくとも部分的に原因である可能性があります。

明白な解決策 (そしておそらく実用的ではない) は、アプリケーションで使用するメモリを減らすことです。それはオプションではないか、少なくとも単純なオプションではないと思います。もう 1 つの方法は、他のアプリケーションを実行するための物理メモリを継続的に確保するために、積極的にデータをディスクにフラッシュすることです。GlobalMemoryStatusExを使用して、マシンの合計メモリを確認できます。また、GetProcessMemoryInfoは、独自のアプリケーションのメモリ使用量に関する現在の情報を返します。メモリマップファイルを使用していると言うので、さらにそれを考慮する必要があるかもしれません。たとえば、PageFileUsageその API から返される情報には、独自のメモリ マップ ファイルに関する情報は含まれないと思います。

アプリケーションが使用状況を監視している場合、 FlushViewOfFileを使用して、データをメモリからディスクにプロアクティブに強制できる場合があります。また、可能な限り多くのダーティ ページをディスクに書き込もうとする API (EmptyWorkingSet) もありますが、それを使用すると、アプリケーションのパフォーマンスが大幅に低下する可能性が非常に高いようです。ただし、アプリケーションが何らかのアイドル状態になることがわかっている状況では役立つ可能性があります。

そして最後に、役に立つかもしれないもう 1 つの API はSetProcessWorkingSetSizeExです。この API を使用して、アプリケーションのワーキング セット サイズの上限に関するヒントを提供することを検討してください。これにより、他のアプリケーション用により多くのメモリを確保できる場合があります。

編集: これはもう 1 つの明白なステートメントですが、前に言及するのを忘れていました。また、実用的ではないかもしれませんが、32 ビットの制限に直面していることを考えると、アプリケーションを 64 ビットとしてビルドし、64 ビット OS で実行することが最善の方法の 1 つに思えます (マシンにもう少しメモリを投入します）。

于 2010-05-12T00:10:30.273 に答える
0

あなたのプログラムには 2GB を超えるワーキング セットが必要なようです。

最新のオペレーティング システムは、RAM の大部分を常に何かに使用するように設計されており、より多くを必要とするプロセスにすぐに割り当てることができるように、かなり少量だけを解放します。残りは、最近使用されたメモリ ページとキャッシュされたディスク ブロックを保持するために使用されます。最近使用されていないものはすべてディスクにフラッシュされ、空きページのプールが補充されます。要するに、多くの空き物理メモリがあるはずがありません。

通常のメモリ割り当てを使用する場合と、ファイルにマップされたメモリを使用する場合の主な違いは、メモリからページアウトする必要がある場合にデータが格納される場所です。メモリがページアウトされるタイミングに必ずしも影響するわけではなく、ページアウトにかかる時間にはほとんど影響しません。

実際に発生している問題は、物理メモリの空き容量が少なすぎることではなく、ページング レートが高すぎることです。

私の提案は、プログラムに必要なストレージの量を減らすことを試み、参照の局所性を増やして必要なページングの量を減らすことができるかどうかを確認することです。

于 2010-05-12T01:08:05.600 に答える