web-dev-qa-db-ja.com

mongodが利用可能なすべてのRAMを使用していないのはなぜですか？

VM上で実行されているmongodインスタンスがあり、使用可能なすべてのメモリを使用しているわけではないようです。これは通常よりも大幅にページ障害が発生しており、システムのパフォーマンスは最近大幅に低下しています。

具体的には、htopmongodの場合、次のように表示されます。

  • VIRT：3471G
  • 解像度：11.8G

VMには約60GBのメモリがあり、現在、約4.6 GBが「使用」されており、残りはバッファまたはキャッシュにあります。

私の理解では、mongodmmapsはデータベースファイルです。 （これがVIRTが巨大な理由です。）ただし、RESがディスクからデータを必要とするためmongodの数値が60GBに近くない理由は明確ではありません。 、このデータはプロセスRSSに取り込む必要がありますね。 Mongoは、ページに障害があると報告しているため、RSSは時間の経過とともに大きくなると考えられます。私たちのものは安定しています。

このマシンで実行されている重要なものは他にありません。 （これはデータベースサーバーです。）残りのバッファーとキャッシュを消費しているのは何ですか。具体的には、RESのサイズがmongodのサイズを拡張して使用可能なRAMを埋めないのはなぜですか？

linuxmongodbdisk-cache
2
Thanatos

これは長くて複雑なプロセスになる可能性がありますが、最初にこれを出発点として言いましょう。私（および私が一緒に仕事をした他の多くの人）は、常駐メモリの最大使用量にはるかに近づくことができました。その最大値が正確に何であるかはシステムごとに異なり、関係する多くの変数がありますが、私は通常60〜80％で撮影しますが、それより高いものはボーナスです。

次にやるべきことは、読書です。このトピックについては、多くの場合、他の観点から多くのことが書かれています（メモリ効率の向上、RAMがいっぱいになったときなど）にさらに適合します）。例：

これらすべてが邪魔にならないので、システムを調整して使用可能なメモリを最大限に活用する方法について適切なアイデアが得られることを願っています（通常、常にではありませんが、先読みをノックダウンして、 NUMAが無効になっている 正常に）、メモリ不足がどこから来ているのかを確認できます。次に理解する必要があるのは少しトリッキーで、MongoDBジャーナルがどのように機能するか、そしてそれがカーネルが個々のプロセスのメモリ使用量を追跡する方法とどのように相互作用するかを含みます。

これは、MongoDB Jiraの長い問題の一部として詳細に説明されています- SERVER-9415 。その問題を調査したときに発見したのは、読み取りと書き込みを組み合わせて実行するときのジャーナルの動作により、MongoDBプロセスで報告された常駐メモリが大幅に減少する可能性があることです（常にではありませんが、再現可能でした）。このメカニズムは Kristina Chodorow here によって詳細に説明されており、Jiraの問題にも詳細があります。

それで、それはどういう意味ですか？

これは、常駐メモリ統計のレポートと解釈が複雑であることを意味します。特に、書き込みも行っているシステムでは、特にそのシステムにmongodプロセス外のメモリプレッシャーがある場合はそうです。一般的に、私は次の方法論をお勧めします。

  • 読み込み（ touch または大規模なクエリ/説明による手動予熱）メモリに収まるはずの大量の既知のデータ
  • そのデータセットに対していくつかのクエリ、集計などを実行し、ページの障害が最小限であることを確認します
  • ページフォールトが少ない場合は、データがメモリに収まっているため、レポートに問題があります。実際の制限が見つかるまで、より大きなデータセットでテストを繰り返すことができます。
  • ページフォールトが高い場合は、データが削除されているか、完全にロードされていないなど、調査する必要があります（先読み、メモリ不足、NUMAが無効になっていることなど）。

通常、テスト中に MMS Monitoring （free）を実行することをお勧めします。これにより、メモリ統計、マップされていないメモリ、ページフォールトなど、および mongostat （1分未満の解像度の場合）何が起こっているのかを適切に把握します。

3
Adam C