問題タブ [virtual-memory]

私が書いているアプリでは、多くのメモリ内コンテナーを使用しています (C++ std コンテナーですが、それは関係ないと思います)。

私のアプリの1つの「タスク」中に、使用率の高いエッジケースでは、プライベートバイトのメモリ使用量が1GBに達します。

ちょっとしたコンテキストとして、このタスクはユーザーが開始した 100,000 個のファイルを含むタスクです。ユーザーがこれを開始してから、マシンを実行したままにする可能性があります。

(そして、ファイルをメモリにロードするようなばかげたことはしません。このフットプリントは、進行中のタスクに関連するすべてのメタデータです)。

ほとんどのユーザーにとって、このタスク中のメモリ使用量はごくわずかです。5,000 の「こと」ではなく、500,000 の「こと」を実行したいユーザーはわずか 1% です。

スクラッチ ファイルや組み込み DB など、このメモリ内の多くのものを何らかの方法でディスクに移動するプロセスに着手しようとしていました。

しかし、「ちょっと待ってください。これらのソリューションはすべて、基本的にメモリをディスクにキャッシュしています。それが仮想メモリの目的ではないでしょうか?」と考えました。

このデータを永続化することには興味がありません。タスクの実行中にアクセスする必要があるのは、純粋にスクラッチ/一時的なものです。

私の質問は、どうすればいいですか？

その 1% の大幅なリファクタリングはしたくありませんが、メモリ フットプリントが大きいアプリを実行した場合の影響を知りたいのです。

とにかく、Windows VM マネージャーよりもはるかに優れた機能はおそらくないだろうと言っているのは正しいでしょうか?

これはどのような条件下で有害になりますか? はい、そうです。実際のメモリをすべて使い果たした場合、ページをリロードするためにスラッシングが発生します。しかし、たとえば組み込みデータベースの場合は、とにかくそれを持っていませんか?

乾杯、

ジョン

パフォーマンス上の理由から共有メモリを使用するプログラムを作成しています（代替手段としてのソケットとパイプが評価されており、これらは私のタスクには十分な速度ではありません。一般的に、コピーを含むIPCメソッドは遅すぎます）。共有メモリ領域では、固定サイズの多くの構造体を書いています。構造体を共有メモリに書き込むためのプログラムが1つあり、そこから読み取る多くのクライアントがあります。ただし、クライアントが書き込む必要のある各構造体のメンバーは1つです（参照カウント。アトミックに更新されます）。他のすべてのメンバーは、クライアントに対してのみ読み取る必要があります。

クライアントはその1つのメンバーを変更する必要があるため、共有メモリ領域を読み取り専用としてマップすることはできません。ただし、他のメンバーをいじくり回してはいけません。これらのプログラムはC ++で記述されているため、メモリが破損する可能性があります。理想的には、あるクライアントが別のクライアントをクラッシュさせることは可能な限り困難である必要があります。私はバグのあるクライアントについてのみ心配しており、悪意のあるクライアントについては心配していないので、不完全な解決策は許可されています。

ヘッダーでconstとして使用するメンバーを宣言することで、クライアントによる上書きを阻止することができますが、それでもメモリの破損（バッファオーバーフロー、不正なキャストなど）による上書きを防ぐことはできません。カナリアを挿入することはできますが、それをチェックするための費用を常に支払う必要があります。

参照カウントメンバーを直接保存する代わりに、構造体を読み取り専用のマップされたページに保持しながら、実際のデータへのポインターを別のマップされた書き込み専用ページに保存することができます。これは機能します。ポイントされたデータに書き込もうとすると、OSによってアプリケーションが強制的にクラッシュしますが、ロックフリーアルゴリズムを書き込もうとすると、間接ストレージが望ましくない場合があります。これは、別のレベルの間接参照に従う必要があると、何かができるかどうかが変わる可能性があるためです。アトミックに行われます。

メモリの小さな領域にマークを付けて、それらを書き込むとアプリが爆発するようにする方法はありますか？一部のプラットフォームにはハードウェアウォッチポイントがあり、インラインアセンブリでそれらの1つをアクティブ化できるかもしれませんが、32ビットx86では一度に4つに制限され、それぞれが制限されているため、構造体の一部しかカバーできませんでした4バイトまで。また、プログラムをデバッグするのが面倒になります;）

編集：私はこのかなり目を見張るような紙を見つけましたが、残念ながら、ECCメモリと変更されたLinuxカーネルを使用する必要があります。

私はc/c++経由でWindowsを読んでいます。そして、大きなファイルをメモリにマップできるのではないかと思います。

アプリケーションを実行すると、PEファイルがプロセスアドレス（ユーザーパーティション）にマップされます。

32ビットWindowsでは、大きなファイル（2GBより大きい）をユーザーパーティションにロードできますか？またはそれは失敗しますか？
可能であれば、ページングファイルは読み込みに役立ちますか？

プログラムは将来近くの情報を必要とする可能性があるため、オペレーティングシステムはプログラムが実際に要求するよりも多くディスクから読み取ります。私のアプリケーションでは、ディスクからアイテムをフェッチするときに、要素の周囲の情報の間隔を表示したいと思います。私が要求して表示する情報の量と速度の間にはトレードオフがあります。ただし、OSはすでに要求したものより多くを読み取るため、すでにメモリ内にあるこれらのバイトへのアクセスは無料です。OSキャッシュに何があるかを調べるためにどのAPIを使用できますか？

または、メモリマップトファイルを使用することもできます。その場合、問題はページがディスクにスワップされているかどうかを確認することになります。これは一般的なOSで実行できますか？

編集：関連論文http://www.azulsystems.com/events/mspc_2008/2008_MSPC.pdf

OS カーネルは仮想メモリを使用していますか、それとも OS カーネルの一部をハードディスクに常駐させることができますか?

最新の x86 CPU は、従来の 4K (つまり 2MB または 4MB) よりも大きなページ サイズをサポートする機能を備えており、この機能にアクセスするための OS 機能 ( Linux、Windows ) があります。

上記のマイクロソフトのリンクでは、大きなページは「変換バッファの効率を高め、頻繁にアクセスされるメモリのパフォーマンスを向上させることができます」と述べています。大きなページが特定の状況を改善するかどうかを予測するには、これはあまり役に立ちません。一部のプログラム ロジック (またはアプリケーション全体) を移動してヒュージ ページを使用することでパフォーマンスが改善された具体的な、できれば定量化された例に興味があります。サクセスストーリーはありますか？

私が知っている特定のケースが 1 つあります。巨大なページを使用すると、大きなプロセスを fork するのに必要な時間が劇的に短縮されます (おそらく、コピーが必要な TLB レコードの数が 1000 分の 1 に減少するため)。それほどエキゾチックではないシナリオでも、巨大なページがメリットになるかどうかに興味があります。

32ビットシステムのアプリケーションで（理論的に）使用できるメモリの量はどれくらいですか？異なるOS？2または1Gb？

どうも！

Linux では/proc/meminfo、多くのメモリ使用統計が表示されます。

それらの間にはかなりの重複があります。たとえば、私が理解している限り、アクティブなページ キャッシュ (「キャッシュ」と「アクティブ」に属する) と非アクティブなページ キャッシュ (「非アクティブ」+「キャッシュ」) が存在する可能性があります。

私がやりたいのは、「空き」メモリを測定することですが、システム全体のパフォーマンスに大きな影響を与えることなく削除される可能性が高い使用済みページが含まれるようにします。

最初は「free」＋「inactive」に傾倒していたのですが、Linuxの「free」ユーティリティは「バッファ調整」表示で「free」＋「cached」を使っているので、どのようなアプローチが良いのか気になります。

カーネルがメモリ不足になった場合、削除するページの優先順位と、使用可能なメモリを測定するためのより適切なメトリックは何ですか?

2 GB の RAM があり、それぞれ 1.5 GB のオブジェクトのインスタンスが 2 つある場合、オペレーティング システムが助けになり、コンテキストによってページがハードディスクとの間で切り替えられます。

インスタンスが 1 つあるのに 3 GB の場合はどうなりますか。同じページング方法で、このインスタンスを 2 つのページに分割できますか? または、メモリ不足の問題が発生しますか?

オブジェクト以外の他のデータ構造にも同じ質問を適用したいと思います。ページングは​​全体としてそれをページングしますか、それとも小さな単位に分割しますか。

ありがとう。

繰り返しになりますが、私は自分が一連の間違った仮定に直面していることに気づきました。記事自体は、実証済みの最適なアルゴリズムを変更して仮想メモリを考慮することにより、パフォーマンスが 10 倍向上することについて説明しています。

いくつかのギガヘルツのクロック周波数で動作する最新のマルチイシュー CPU では、最悪の場合の損失は、VM ページ フォールトごとに約 1,000 万命令です。回転ディスクで実行している場合、その数は 1 億の命令に近くなります。

O(log2(n)) アルゴリズムは、これらの操作がページ フォールトやディスク操作の低速化を引き起こす場合、何の役に立つでしょうか? 最も関連性の高いデータセットでは、ページ フォールトを回避する O(n) または O(n^2) アルゴリズムでさえ、その周りを円で囲みます。

そのようなアルゴリズムはもっとありますか? 教育の基本的な構成要素をすべて再検討する必要がありますか? 自分で書くとき、他に何に注意する必要がありますか?

説明:

問題のアルゴリズムは、Big-O 表記に欠陥があるか無意味であるため、実証済みの最適なアルゴリズムよりも高速ではありません。実証済みの最適なアルゴリズムは、最新のハードウェア/OS では当てはまらない仮定、つまりすべてのメモリ アクセスが等しく交換可能であるという仮定に依存しているため、高速です。