MongoDB の配置はトランザクション量が多い大規模なデータベースをサポートするため、パフォーマンスの調整が重要になります。定期的に調整することで、クラスター内の問題を早期に特定し、システムの応答性や安定性に影響前にその問題に対処することができます。
このドキュメントでは、パフォーマンス 調整と有用なメトリクスを使用して配置パフォーマンスを最適化する一般的な方法について説明します。これらのメソッドは、MongoDB Atlasクラスターと自己管理型配置の両方に適用されます。ただし、 MongoDB Atlasを使用すると、調整プロセスは大幅に容易になります。これにより、多くのタスクとストリームラインが自動化され、効率が向上します。パフォーマンスの詳細については、 MongoDBパフォーマンス を参照してください。
クエリを高速で実行
最適なクエリ パフォーマンスを確保するには、 メトリクス を使用してクエリ パフォーマンスの問題を示し、遅いクエリが見つかった場合の対応を示すメトリクスを使用できます。
MongoDBログファイルには、各クエリの実行時間と方法がレコード、低速クエリを検索できるようになります。データベースプロファイラは、指定されたしきい値を超えるクエリをログに記録します。
クエリが遅い場合は、まずクエリプランにアクセスしてください。クエリプランデータの検索の詳細については explain の結果 を参照してください。
クエリがコレクションスキャンではなくインデックススキャン を実行したことを確認します。
インデックススキャンではMongoDB が検査するドキュメントの数が制限されますが、コレクションスキャンではMongoDB がコレクション内のすべてのドキュメントを読み取る必要があります。プラン結果の解釈方法の詳細については、説明プラン結果の解釈を参照してください。
説明プランの結果に多くのコレクションスキャンが表示される場合は、インデックスの追加 を検討してください。
注意
インデックスは書込みや更新を遅くする可能性があるため、使用されていないインデックスが多すぎると、ワークロードによってはドキュメントの変更や挿入が妨げられる可能性があります。
クエリ メトリクス
また、次のクエリメトリクスを使用して、クエリが最上位で実行中ようにすることもできます。
metrics.queryExecutor.scannedは、クエリ結果を返すまでにスキャンされたドキュメントの数を示します。理想的には、スキャンされた文書と返された文書の比率は 1:1 で、 MongoDB はすべてのドキュメントを返します。通常、この比率は 1 より大きく、 MongoDB はスキャンされたドキュメントの一部を返さないことを示します。
この比率は 1 未満、あるいは 0 未満になる可能性があり、インデックスに必要なデータがすべて含まれているカバード クエリであることを示します。
MongoDB がクエリに応答するために多数のドキュメントをスキャンしている場合は、インデックスが欠落しているか、クエリを最適化する必要がある可能性があります。
metrics.operation.scanAndOrderは、クエリ結果をソートするためのサーバーの労力を示します。20 以上などの高いスキャンと注文数の場合は、サーバーで結果をソートする必要があることを示し、クエリ結果時間とサーバーメモリ負荷が増加します。
高いスキャンと注文数を修正するには、クエリ要件に従ってインデックスをソートするか、欠落しているインデックスを追加します。通常、 b 木インデックスは、複合インデックスの場合、インデックスの先頭フィールドから昇順でソートします。
WiredTigerチケット番号メトリクスは、 WiredTigerストレージエンジンのパフォーマンスを反映します。
WiredTiger の読み取りチケットと書き込みチケットは、同時トランザクションの数を管理するためのWiredTigerストレージエンジンの同時実行制御メカニズムです。バージョン 7.0 以降、MongoDB は、動的アルゴリズムを使用して、ストレージストレージエンジントランザクションの最大数を調整し、クラスターの過負荷時にデータベーススループットを最適化します。
読み取りチケットと書き込みチケットは同時トランザクションの最大数を制御します。WiredTigerチケット番号は常に 128 である必要があります。継続的な値が 128 未満の場合は、サーバーの遅延とそれに関連する潜在的な問題が発生していることを示します。
serverStatusコマンドを使用して、現在の読み取りチケットと書き込みチケットの数と使用状況を確認できます。現在の負荷とチケットの可用性を理解するには、queues.executionセクションを参照してください。WiredTigerチケットの数が少ない場合は次の手順で行います。
チケット割り当てを自動的に管理するには、 動的調整 機能が有効になっていることを確認します。
CPU やメモリなど、ワークロードを処理するのに十分なリソースがクラスターにあることを確認します。
MongoDB 3.2 またはそれ以前のバージョンを使用している場合は、 WiredTigerを使用する以降のバージョンにアップグレードしてください。
同時トランザクションの最大数を手動で調整する必要がある場合は、 パラメータと
storageEngineConcurrentReadTransactionsstorageEngineConcurrentWriteTransactionsパラメータを変更できます。
注意
storageEngineConcurrentReadTransactions と storageEngineConcurrentWriteTransactions を変更するときは注意してください。これらの設定を変更するとパフォーマンスの問題やエラーが発生する可能性があるためです。これらのパラメーターを変更する前に、 MongoDBサポートに確認することをお勧めします。
ドキュメント構造の排他的
クエリプランには、ドキュメント構造のウイルス対策を明らかにするメトリクスは含まれていませんが、低速クエリをデバッグするときにインターフェースを探すことができます。パフォーマンスを損なう、次の最も一般的な不適切なクエリプラクティスに注意してください。
無制限配列: サイズ制限なしで大きくなるドキュメント内の配列はパフォーマンスの問題を発生させます。配列を更新するたびにMongoDB は配列をドキュメントに書き換える必要があるためです。詳細については、無制限の配列の回避を参照してください。
境界のない埋め込みドキュメント: MongoDB は、最大 128 レベルのネストでドキュメント内にドキュメントを挿入することをサポートしています。埋め込みドキュメントを含む各MongoDBドキュメントのサイズ制限は 16MB です。埋め込みドキュメントの数が多すぎると、パフォーマンスの問題が発生する可能性があります。
過剰な埋め込みドキュメントを軽減するには、埋め込みドキュメントを別のコレクションに移動し、元のドキュメントから参照。詳細については、肥大化されたドキュメントを参照してください。
最高速度のデータベースを保証
MongoDBには、データベースの読み取り、書込み (write)、クエリなどのデータベースのパフォーマンスのあらゆる要素を追跡するだけでなく、バックアップのようなバックグラウンドのメンテナンス タスクがパフォーマンスを妨げないようにする数百万のメトリクスがあります。次のメトリクスは、データベースに問題があることを示しており、データベースの最適なパフォーマンスを確保できます。
Replication Lag
レプリカセットのセカンダリ ノードがプライマリより遅れると、レプリケーションラグが発生します。レプリケーションラグの原因を理解するには、oplog関連のメトリクスを調べることができます。ただし、次の問題はレプリケーションラグの最も一般的な原因です。
プライマリとセカンダリ間のネットワークの問題があり、ノードにアクセスできなくなる
プライマリノードよりも遅いデータを適用するセカンダリノード
書込みキャパシティーが不十分 、その場合はシャードを追加する必要があります
プライマリノードでの低速操作、レプリケーションのブロック
ロック パフォーマンスの問題
MongoDB の内部ロック システムは、書込み競合や不整合な読み取りを回避しながら、同時クエリをサポートするために使用されます。ロックの結果であるパフォーマンスの問題は、使用可能な読み取りチケットまたは書き込みチケットの残り数が 0 に達したときに発生します。つまり、新しい読み取りまたは書き込みチケットが使用可能になるまで、新しい読み取りまたは書き込みリクエストはキューに入れられます。
ロック パフォーマンスの問題は、インデックスが最適ではなく、スキーマ設計パターンが不十分であることを示している可能性があり、その両方でロックが必要以上に保持される可能性があります。
オープン カーソル
オープン カーソルの数が増加しても、それに応じてトラフィックが増加しない場合は、インデックスが不十分なクエリを実行しているか、結果セットが大きいためにクエリの実行が長時間化している可能性があります。
過負荷クラスター
パフォーマンスを調整する際には、合計トラフィックまたはシステムを介するトランザクションのスループットが、クラスターの計画キャパシティーを超えて増加していることを認識することが重要です。スループットの増加を追跡することで、クラスターのキャパシティーを効率的に拡張できます。
次のメトリクスは、クラスターのスループットを追跡するのに役立ちます。これらのメトリクスを見つけるには、serverStatus コマンドを実行し、以下に指定されたフィールドを確認します。
読み取り操作と書込み操作
読み取り操作および書込み操作 のメトリクスは、クラスターが実行する作業量を示します。opcounters.queryフィールドから読み取り操作を、 opcounters.insert、 opcounters.update、 opcounters.deleteを通じて書込み操作を見つけることができ、それぞれの挿入、更新、削除操作の合計数をカウントします。
読み取りと書込みの比率は、クラスターで実行中ワークロードの性質によって異なります。
読み取り操作と書込み (write) 操作を一定の期間モニタリングすることで、通常の範囲としきい値を確立できます。
読み取りおよび書込み (write) 操作の傾向がスループットの増加を示すにつれて、キャパシティーを徐々に増加させることができます。
ドキュメント メトリクスとクエリ エグゼキュータ
ドキュメント メトリクス と クエリ実行プログラム は、クラスターが多すぎる場合を示します。読み取り操作および書込み (write) 操作のメトリクスと同様に、これらのメトリクスに正しい数値も誤った数値もありませんが、通常の数値とは何ですか。パフォーマンスが低下しているのはワークロードサイズが大きいためか、他の理由に原因があるかが識別できます。
ドキュメント メトリクスを検索するには、metrics.keysExamined フィールドと metrics.totalExecMicros フィールドにアクセスします。クエリ実行メトリクスを検索するには、metrics.fromPlanCacheフィールドを確認します。これらのフィールドはすべて、$queryStats集計ステージを使用して見つけることができます。
MongoDB は、ドキュメントを見つけた、またはドキュメントを挿入するたびにドキュメントメトリクスを更新します。検索、挿入、更新、または削除するドキュメントが多いほど、クラスターは使用されます。
十分なキャパシティーがあるクラスターでパフォーマンスが低下している場合は、通常クエリの問題が発生します。
クエリエグゼキュータは、2 つのデータ ポイントを使用して処理されるクエリの数を示します。
スキャン: クエリおよびクエリプランの評価中にスキャンされたインデックス項目の、選択したサンプル期間における 1 秒あたりの平均レート。
スキャンされたオブジェクト: クエリおよびクエリプランの評価中にスキャンされたドキュメントの、選択したサンプル期間における 1 秒あたりの平均レート。
ハードウェアとネットワーク メトリクス
ハードウェアとネットワークのメトリクスは、スループットが増加しており、コンピューティング インフラストラクチャのキャパシティーを超えていることを示している可能性があります。これらのメトリックは、オペレーティング システムとネットワーク インフラストラクチャから収集されます。これらのメトリクスを診断目的で役立ちます。通常のことを理解している必要があります。
MongoDB をオンプレミスで実行中いる場合は、オペレーティング システムによっては、MongoDB Ops Managerを使用してハードウェアとネットワークのメトリクスを表示できる場合があります。
追跡するメトリクスは多数ありますが、ベースライン範囲を設定するための重要なメトリクスがいくつかあります。
Disk Latency
Disk IOPS
接続数
クラスターとキー リソース
MongoDBクラスターは、基礎のコンピューティングとネットワーク インフラストラクチャが提供するさまざまなリソースを使用します。
クライアント接続数
ドキュメントの フィールドにあるconnections.current [serverStatus 現在のクライアント接続数 ] メトリクスは、システムの合計負荷を示す可能性があります。1 日や週のさまざまな時間ごとに正常範囲を追跡することで、トラフィックの急増を迅速に特定できます。
関連メトリクス（使用済み接続の割合）は、 MongoDB が利用可能な接続の実行中に近づいていることを示します。
ストレージ メトリクス
ストレージ メトリクスは、 MongoDB が永続的ストレージを使用する方法を追跡します。WiredTiger ストレージエンジンでは、各コレクションと各インデックスは個別のファイルです。コレクション内のドキュメントを更新すると、 MongoDB はドキュメント全体を再書き込みします。
dbStats.dataSize、dbStats.indexSize、dbStats.storageSizeやデータベース内のドキュメント数などのメモリ空間メトリクスに、データベーストラフィックが通常の範囲内に維持されている間に大きく予期しない変化が見られる場合は、データの削除や破損などの問題が発生している可能性があります。 、予期しないデータの増加、インデックスの変更。dbStats.dataSizeが急増した場合は、大量のデータが削除されている可能性があります。この削除が予期しない場合は、迅速に調査する必要があります。
メモリ メトリクス
メモリ メトリクスは、 MongoDB がクラスターをホストしているコンピューティング インフラストラクチャの仮想記憶をどのように使用しているかを示します。メモリ メトリクスは、memドキュメントの serverStatus の結果で確認できます。
ページフォールトの数が増加したり、変更されたがまだディスクに書き込まれないデータ量が増加したりする場合は、クラスターで使用可能なメモリの量に問題がある可能性があります。
キャッシュ メトリクスは、ワーキングセットが使用可能なキャッシュよりも増大しているかどうかを判断するのに役立ちます。
重大なエラー
MongoDB は、主にログ プロセスの一部としてMongoDB がキャプチャするエラーを使用してアサートを作成します。
さまざまな重大度レベルで作成されたアサートの数をモニタリングすることで、予期しない問題の初期レベルの指標を得ることができます。アサートは、メッセージ アサート、最も重大な種類、または警告アセット、通常のアサート、およびユーザー アサートになります。