Make the MongoDB docs better! We value your opinion. Share your feedback for a chance to win $100.
Click here >
Docs Menu
Docs Home
/ /

本番環境での低速クエリのトラブルシューティング

このページでは、低速クエリの一般的な原因と解決策について説明します。以下のセクションを行った後に追加のサポートが必要な場合は、 テクニカル サポートにお問い合わせください。

配置で低速クエリに関する問題が発生していることを確認するには、以下を確認します。

クエリが実際に遅いことを確認するには、現在のクエリレイテンシを履歴ベースラインまたはサービス レベルのオブジェクトと比較します。低速が一定であるか、負荷のスパイク、バッチするジョブ、メンテナンスウィンドウなど特定の負荷パターン中に発生するかを特定します。

データベースプロファイラと低速クエリ ログを使用して、名前空間、 パターン、レイテンシで特定の操作を識別します。

Atlas では、 Performance Advisor とクエリプロファイラーを使用して、実行時間が長いクエリを見つけます。

クラスターとノードの正常性を確認します。次のコマンドで問題を確認します。

  • プライマリ/セカンダリ 状態

  • レプリケーションラグ

  • 頻繁に行われる選挙

  • ノードの可用性

  • フェイルオーバー

  • Node restarts

  • 低速クエリ期間と同時に発生するストレージ エラー

各ノードの CPU、メモリ、ディスク I/O、ディスク使用率を検査し、継続的な飽和状態がないことを確認します。詳細については、「 自己管理型MongoDB配置のモニタリング 」を参照してください。

Atlas では、低速クエリの時点で CPU、IOPS、接続、ページフォールトが急増しているかどうかのメトリクス ダッシュボードを確認します。

以下のような低速クエリと同時に最近の変更が発生したかを判断します。

  • アプリケーションのリリース

  • インデックスの変更

  • スキーマの移行

  • 配置のサイズ変更

  • パラメーターの変更

次のセクションでは、クエリが遅くなる一般的な原因とその解決方法について説明します。

以下のインデックス作成の問題は、低速クエリの原因となります。

コレクションスキャンを実行するクエリ、または非選択性のインデックスを使用するクエリでは、本番環境の負荷下で高レイテンシが発生する可能性があります。高冗長の場合は、 または オプションとともに を使用し、期待されるインデックスを使用していないクエリを識別します。これらのオプションは、評価フェーズ中にすべてのプランの実行メトリクスを表示します。クエリ結果をフィルタリングおよびソートするために使用されるフィールドのインデックスを作成または調整します。explain"executionStats"“allPlansExecution”

sort()インデックスを使用できない のクエリには、メモリ内でのソートが必要です。これは、大規模な結果セットでは特に遅くなります。パフォーマンスは、次の方法で向上できます。

集計パイプラインでは、データセットをフィルタリングして、メモリ内の大量のデータを処理しないようにするために、$match$sort、またはその他の選択的ステージを早期に使用する必要があります。パイプラインに遅い $match ステージまたは $sort ステージがある場合は、可能な限り早期に移動します。

また、初期のパイプラインステージで使用されるフィールドにインデックスを作成することでパフォーマンスを向上させることもできます。

以下のスキーマとクエリ設計の問題は、低速クエリを引き起こす可能性があります。

非常に大きなドキュメント、境界のない配列、高度にネストされた構造では、 1 回の操作あたり I/O と CPU が増加します。異常に大きいドキュメントや幅広い配列を持つコレクションを識別し、可能な場合はバケットまたは参照を使用するようにスキーマを更新することで、パフォーマンスを向上させることができます。

大規模なコレクションまたは時間範囲をスキャンするクエリは、厳密なフィルターと制限を強制するクエリよりも遅くなります。クエリのパフォーマンスは、次の方法で向上できます。

  • 選択性フィルターの追加と、クエリされたフィールドのインデックス作成

  • またはskip()limit() の大規模な組み合わせではなく、ページ分割パターンを使用する

  • 時系列データの時間枠を絞り込むか、基礎となるコレクション自体の粒度が細かい場合は調整します。

一部のクエリ演算子とパターンは、 MongoDB がインデックスを効率的に使用することを妨げます。

  • $regex 先頭のワイルドカードがある

  • $nin

  • 非常に大きな$in リスト

  • 過剰な ブランチ$or

  • $ne インデックススキャンに悪影響を影響否定式

パフォーマンスを向上させるには、述語をインデックスに対応するように書き換えます。可能な場合は、アンカー正規表現と事前計算フィールドを検討してください。

低速クエリは、本番環境の負荷下での基礎のハードウェアリソースの競合が原因で発生する可能性があります。クエリレイテンシの急増と CPU、IOPS、キャッシュ使用率のメトリクスとの間に相関関係があるかどうかを確認します。クエリがすでに最適化されている場合は、垂直および水平のスケーリングやワークロードの再分散を検討してください。

実行時間が長い操作は、他のクエリをブロックしたり干渉したりする可能性があります。 (例: )。

  • 大規模なインデックスビルド

  • コレクションスキャン

  • 重い書込み (write)

$currentOpブロッキング操作または長時間実行される操作を識別するには、 を使用します。メンテナンスウィンドウ中に重い操作を予定することを検討してください。例、メンテナンスウィンドウ中に大規模なコレクションのインデックスビルドを実行中場合を考えてみましょう。

レプリケーションラグのあるセカンダリにルーティングされたクエリは、またはパフォーマンスの低いハードウェアではルーティングされません。ドライバーの読み込み設定(read preference)と書込み保証(write concern)を確認します。レイテンシの重要なクエリが適切なノードに誘導されるようにします。

  • 一般的なクエリを再実行し、レイテンシを以前の結果と目的の目標と比較します。

  • explain("executionStats") が検査されるドキュメントの数を減らし、インデックス使用量の改善など、作業の削減を示していることを確認します。

  • プロファイラーと低速クエリのログ を確認して、次のいずれかを確認します。

    • 以前の低速クエリは表示されなくなりました。

    • クエリ時間とリソース使用量が減少しました。

  • Atlas 配置の場合、変更後にクエリレベルとクラスターレベルのメトリクスが通常の範囲に戻っていることを確認します。

追加のサポートが必要な場合は、次の情報を収集してください。

  • 完全なフィルターと、次のような該当するプロジェクション、ソート、およびオプションを使用して低速クエリをサンプリングします。

    • おおよその頻度

    • 予想されるレイテンシと観察されたレイテンシ

  • explain("executionStats") 低速クエリの 出力

  • 低速が発生している期間をカバーする関連するログの抽出とプロファイラーのサンプル

  • 最近の変更は:

    • スキーマまたはインデックス

    • 配置のサイズ、階層、またはトポロジー

    • アプリケーション リリースまたはクエリ パターン

  • 遅いクエリが発生している時点での CPU、メモリ、ディスク I/O、および接続使用量を示すクラスター メトリクスまたはホスト レベルの統計情報。

  • 配置環境の詳細:

    • Atlas と自己管理型

    • ハードウェア プロファイル

    • シャーディング構成

    • レプリケーション構成

戻る

低速クエリのブロック

項目一覧