記事のディレクトリ
1つは、MongoDBのメモリ使用量の概要です
MongoDBのメモリ消費には、主に2つの部分があります。
1、存储引擎
2、client建立的连接的请求处理
1.1ストレージエンジンのメモリ消費
MongoDBバージョン3.2以降、デフォルトのストレージエンジンはwiredtigerです。wiredtigerストレージエンジンはcacheSizeGBで制御できます。通常、このパラメーターはシステムの使用可能なメモリの60％に設定することをお勧めします。
MongoDBは、メモリアロケータとしてGoogletcmallocを使用します。メモリが特定のしきい値に近づくと、メモリがいっぱいになったときにユーザーリクエストがブロックされないように、メモリが削除され始めます。
Tcmallocメモリ除去メカニズム：
| パラメータ | デフォルト | 意味 |
|---|---|---|
| eviction_target | 80 | 使用されるキャッシュがeviction_targetを超えると、バックグラウンドのエビクトスレッドがCLEANPAGEの削除を開始します |
| eviction_trigger | 95 | 使用されるキャッシュがeviction_triggerを超えると、ユーザースレッドもCLEANPAGEの削除を開始します |
| eviction_dirty_target | 5 | キャッシュダーティがeviction_dirty_targetを超えると、バックグラウンドのエビクトスレッドがダーティページの削除を開始します |
| eviction_dirty_trigger | 20 | キャッシュダーティがeviction_dirty_triggerを超えると、ユーザースレッドもダーティページの削除を開始します |
このルールでは、通常実行されているmongodbインスタンスのメモリ使用量はcacheSizeGBの約0.8であり、場合によってはそれを超えても問題はありません。
使用> 90％またはダーティ> 20％が引き続き表示される場合は、メモリ除去の圧力が非常に高く、ユーザーの要求スレッドがページ除去に参加するためにブロックされ、要求の遅延が増加することを意味します。現時点では、[メモリの増加]または[より強力なIO機能を備えたディスクの交換]を検討できます。
1.2TCP接続とリクエスト処理
1.TCPプロトコルスタック
ソケットメタデータ、各スレッドの読み取りバッファー/書き込みバッファー、およびユーザーの送受信ネットワークパケット
バッファーのサイズは、次のsysctlシステムパラメーターを介して構成されます。
2.スレッドスタックを要求します
MongoDBは、接続ごとに個別のスレッドを作成します。mongodは、
接続要求を処理するスレッド用に最大1MBのスレッドスタック（通常は約数十KB）を構成します。
これらのスレッドスタックの実際のオーバーヘッドは、procファイルシステムで確認できます。
3.バックグラウンドスレッドスタック
メインとスタンバイの同期、ジャーナル、TTL、エビクト、その他のスレッドの定期的な更新各スレッドの
デフォルトの最大ulimit -s（通常は10MB）スレッドスタック
4. MongoDBクライアントは、メモリを消費するための接続をどのように作成しますか？
1）各スレッドには、独自のローカル空きページキャッシュと中央の空きページキャッシュがあります
。2）メモリを申請するとき、検索を続行しない場合は、最初にローカル空きページキャッシュから使用可能なメモリを照会します。中央の空きページキャッシュで使用可能なメモリ
3）それでも使用可能なメモリが見つからない場合は、ヒープに移動してメモリを申請します
。4）メモリが解放されると、メモリは最初にキャッシュに戻され、その後、tcmallocはゆっくりとOSに返されます。
2.MongoDBのメモリ使用量を制御する方法
2.1cacheSizeGBの合理的な構成
cacheSizeGBパラメーターと実際のサーバーRAM構成を使用して、メモリ制限を合理的に設定します。通常、cacheSizeGBパラメーターを使用可能なメモリの60％に設定することをお勧めします。もちろん、現在のサーバーで大量のメモリを消費する他のサービスがあるかどうかも考慮する必要があります。
2.2同時接続の数を制御する
-
アプリケーションレベルの
MongoDBドライバーは、mongodに接続するときに接続プール（通常はデフォルトで100）を維持します。多数のクライアントが同時に同じmongodにアクセスする場合は、各クライアントの接続プールのサイズを小さくすることを検討する必要があります。 -
データベースレベルで
は、net.maxIncomingConnectionsを使用して、同時MongoDB接続の数を制限し、データベースの過負荷を防ぎます。
データベースレベルからの同時接続制御は、私たちの最後の防衛線です。さらに重要なことは、同時要求の数が多いのは、実際のビジネスプレッシャーが大きすぎるのか、クエリ実行効率が低すぎてセッションが発生しないのかをさらに分析する必要があります。やり残し。
2.3スワップを構成する
スワップが構成されている場合、MongoDBサービスのOOMを効果的に防ぐことができますが、メモリが不足している場合、スワップを頻繁に使用するとデータベースのパフォーマンスに深刻な影響を及ぼします。
最適なシナリオは、MongoDBサービスに十分なメモリを構成し、メモリが不足している場合は、時間内に容量を拡張することです。
2.4その他
1）メモリソートのシナリオを最小限に抑えます。メモリソートには通常、より多くの一時メモリが必要です
。2）アクティブノードとスタンバイノード間の構成ギャップは大きすぎないようにする必要があります。スタンバイノードは、ストレージとプル用のバッファ（デフォルトは最大256MB）を維持します。バッファ内のoplogは継続的に再生されます。バックアップの同期が遅い場合、バッファは引き続き最大メモリを使用します。
3）コレクションとインデックスの数を制御して、メタデータを管理するためのデータベースのメモリオーバーヘッドを削減します。コレクションとインデックスが多すぎると、メタデータメモリのオーバーヘッドが影響し、起動時の読み込みと実行時のパフォーマンスの効率に影響します。
参照ドキュメント：
https ：//yq.aliyun.com/articles/685044？spm = a2c4e.11155435.0.0.155a135eYaJeyU