最適化が必要な低速な操作を見つけるために、いくつかの Mongo ログを grep で検索しようとしています。低速クエリのログ記録はデフォルトで、100 ミリ秒を超える操作がログに記録されます。
一般的に言えば、COLLSCANS を検索すると、注意が必要なクエリが表示されると言っても過言ではないと思います。IXSCANS が検索すべき詳細であるかどうかは、あまり明確ではありません。
ここで MongoDB のドキュメントを検討します:
https://docs.mongodb.com/manual/reference/explain-results/#collection-scan-vs-index-use
私の理解では、これはバイナリ状況であり、クエリは COLLSCAN または IXSCAN のいずれかです。したがって、IXSCAN を grep すると、COLLSCAN ではないすべての低速クエリが表示されます。これは本当ですか?
答え1
最適化が必要な低速な操作を見つけるために、いくつかの Mongo ログを grep で検索しようとしています。低速クエリのログ記録はデフォルトで、100 ミリ秒を超える操作がログに記録されます。
MongoDBのログをgrepするよりも、オープンソースのスクリプトを使用することを強くお勧めします。mtools
プロジェクト注: 私は原作mtools
者ではありませんが、寄稿者の一人です。
mtools
は、実稼働の MongoDB デプロイメントで興味のある情報を見つけるために、何 GB ものログを grep で検索する苦労からヒントを得た Python スクリプトのコレクションです。主要なスクリプトは、出力を連続するフィルターにパイプする一般的なコマンド ライン ワークフローに適合するように設計されています (例: mlogfilter --scan | mplotqueries
)。
例えば:
mloginfo --queries
は良い出発点です。クエリ パターンを集約することで、頻繁に実行され、展開全体に大きな影響を与えるクエリに集中できます。mlogfilter
は基本的にMongoDBログのgrepです。名前空間、期間、接続、パターン、その他の基準でログ行をフィルタリングできます。--scan
このオプションは、必ずしもコレクションスキャンではない非効率的なクエリを識別するのに役立ちます。mplotqueries
ログを視覚化するツールであり、パターンや外れ値を識別するのに非常に役立ちます。
一般的に言えば、COLLSCANS を検索すると、注意が必要なクエリが表示されると言っても過言ではないと思います。IXSCANS が検索すべき詳細であるかどうかは、あまり明確ではありません。
コレクションスキャンは一般的に興味深いものですが、1回限りのクエリや小さなコレクションでの予想される使用の結果である可能性もあります。クエリの種類に焦点を当てるのではなく、デプロイメントの遅いクエリ(または一般的な遅い操作)を確認して、改善できる可能性のあるものをよりよく理解することをお勧めします。インデックスを使用することは通常は良いことですが、非効率的なインデックスの使用法があります(例:メモリ内ソートや大文字と小文字を区別しない正規表現)に対処する価値があるかもしれません。
私の理解では、これはバイナリ状況であり、クエリは COLLSCAN または IXSCAN のいずれかです。したがって、IXSCAN を grep すると、COLLSCAN ではないすべての低速クエリが表示されます。これは本当ですか?
grep すると、 にIXSCAN
言及しているすべてのログ行が見つかりますIXSCAN
が、遅いクエリのログ出力はバイナリではなく、MongoDB サーバーのバージョンによっても異なります。効率的なインデックスの使用は明らかに最適化ですが、内部的にいくつかの問題があります。クエリプランナーのステージクエリのパフォーマンスを理解する上で関連がある可能性があります。
ログで興味深い遅いクエリを見つけたら、次のステップは通常、より詳細な調査です。explain output
. 私はexplain(true)
(別名allPlansExecution
モード)では、考慮されたクエリプランの詳細と、選択されたプランが表示されます。遅いクエリのexplain出力をどのように解釈すればよいか分からない場合は、投稿することをお勧めします。DBA スタックエクスチェンジ。
クエリの説明は、ワークロードの実際のパフォーマンスの尺度ではないことに注意してください。通常の操作ではクエリプランはキャッシュされますが、詳細なexplain
出力では候補インデックスとクエリプランが具体的に再評価されます。クエリプラン詳細については、MongoDB マニュアルを参照してください。