MongoDBのメモリ使用量の追跡

MongoDBのメモリ使用量を理解することは、MongoDBの優れたホスティングエクスペリエンスにとって非常に重要です。最高のパフォーマンスを得るには、ワーキングセットをメモリ内に保持することが不可欠です。ソリッドステートドライブ（SSD）を使用すると、メモリの重要性が低くなるという提案をいくつか見てきました。ダイナミックランダムアクセスメモリ（DRAM）のアクセス時間はナノ秒のオーダーであり、SSDのアクセス時間はマイクロ秒のオーダーであり、ハードディスクのアクセス時間はミリ秒のオーダーです。したがって、SSDにはまだ追いつく方法があります。メモリ付き。

MongoDBは、メモリマップトファイル（MMF）を使用してデータベースをメモリにマップします。データは定期的にディスクにフラッシュされます（明らかに、メカニズムははるかに複雑ですが、それは別の投稿のトピックです）。

MongoDBサーバーが稼働したら、メモリ使用量を監視して理解することが重要です。 MongoDBサーバーを監視するには、ScaleGridMongoDB監視コンソールを使用してパフォーマンスの詳細な指標を確認できます。いくつかのサンプルワークロードを実行し、ベースラインを確立して、何かが正常に実行されていないときを理解できるようにします。 MongoDBのメモリ使用量を監視するのに役立つ4つの重要なカウンターを次に示します。

1. メモリ

   

   これは、実際には1つのグラフに3つのカウンターがあります：

   1. 常駐メモリ

      これは、MongoDBプロセスによって使用されている物理メモリの実際の量です。

   2. マップトメモリ

      これは、MongoDBの進行状況がデータベースをメモリにマップするために使用する仮想メモリの量です。これは通常、データベースのサイズになります。

   3. 仮想メモリ

      これには、MongoDBプロセス全体の仮想メモリが含まれます。ジャーナル処理をオンにしている場合、これは通常、マップされたメモリの2倍のサイズになります。

2. マップされていない仮想メモリ

   

   これは、データファイルのマッピングではなく、簿記データに使用される仮想メモリの量です。たとえば、各接続は特定の量のメモリを消費します。通常、このカウンターはかなり低くする必要があります。通常は1GB未満です。

3. ページフォールト

   これは、ハードページフォールト/秒の数です。明らかに、この数をできるだけ少なくする必要があります。

   • ハードページフォールト

     これは、問題のページが物理メモリになく、ディスクからフェッチする必要がある場合にトリガーされます。

   • ソフトページフォールト

     これは、ページがメモリ内の別の場所にあるか、移行状態にある場合に発生します。

4. Bツリー（インデックスミス）

   

   インデックスミスは2倍非効率的です。これは、2つのディスク読み取りを引き起こします。1つはインデックスエントリを読み取り、もう1つはドキュメントを読み取ります。 Bツリーカウンターは、インデックスミスの数を追跡します。これは、異常なパターンを見つけるためのベースラインを確立する必要があるもう1つの場所です。 .explain（）コマンドを使用して、一般的なクエリのクエリプランを確認します。

MongoDBのメモリ管理のもう1つの重要な側面は、「ワーキングセット」を理解することです。次の投稿では、データベースのワーキングセットを決定する方法を検討します。