mongotopとmongostatを使ったMongoDBパフォーマンスメトリクスの分析ガイド

mongotopとmongostatを使用して、ホットコレクション、リソースプレッシャー、接続スパイク、遅いMongoDBパターンを特定します。

mongotopとmongostatを使ったMongoDBパフォーマンスメトリクスの分析ガイド

MongoDBのパフォーマンス問題は、多くの場合、ページの遅延、書き込みの滞留、または突然の接続スパイクとして現れます。MongoDB Database Toolsに含まれるmongotopmongostatは、サーバーが現在何を行っているかをターミナルで素早く確認できる手段を提供します。

このガイドでは、一般的なインシデント発生時にこれらのツールを読み解き、その出力をインデックス、クエリ形状、コネクションプーリング、ディスクプレッシャーなどの次の確認項目に結び付ける方法を示します。

mongotopの理解

mongotopは、MongoDBインスタンスで発生している読み取りおよび書き込み操作をリアルタイムで表示します。指定された間隔で各コレクションが読み取りまたは書き込み操作に費やした時間を表示します。これは、どのコレクションが最もアクティブで、パフォーマンス低下の原因となっている可能性があるかを特定するのに特に役立ちます。

mongotopが提供する主なメトリクス:

  • ns: コレクションの名前空間(データベース.コレクション)。
  • total: サンプル間隔中に名前空間の読み取りと書き込みに費やされた時間。
  • read: サンプル間隔中に読み取りアクティビティに費やされた時間。
  • write: サンプル間隔中に書き込みアクティビティに費やされた時間。

mongotopの使用方法:

MongoDBデータベースツールがインストールされ、PATHが通っていれば、ターミナルから直接mongotopを実行できます。デフォルトでは1秒ごとに更新されます。間隔を秒単位で指定することもできます。

mongotop

更新間隔を指定する場合(例:5秒ごと):

mongotop 5

別のホストやポートで動作しているMongoDBインスタンスに対してmongotopを実行する場合:

mongotop --host <ホスト名> --port <ポート>

mongotopの出力の解釈:

  • 特定のコレクションでのwrite時間が高い: そのコレクションで書き込みアクティビティが多くなっています。書き込み量、ドキュメントの増加、書き込みによって触られるインデックス、およびワークロードをシャーディングすべきかどうかを確認してください。
  • read時間が高い: そのコレクションのクエリプランを確認してください。インデックスの欠如、大きな結果セット、集計スキャンが原因であることがよくあります。
  • 一貫してtotal時間が高いコレクション: これらが最もホットなコレクションです。インデックス、ワーキングセット、クエリパターンを注意深く監視してください。

mongostatの理解

mongostatは、MongoDBインスタンスのパフォーマンスとリソース使用率に関する、より広範なリアルタイムの概要を提供します。サーバーの状態に関するさまざまなメトリクス(1秒あたりの操作数、ネットワークトラフィック、ディスクI/O、メモリ使用量など)を収集して表示します。

mongostatが提供する主なメトリクス:

  • insert: 1秒あたりの挿入操作数。
  • query: 1秒あたりのクエリ操作数。
  • update: 1秒あたりの更新操作数。
  • delete: 1秒あたりの削除操作数。
  • getmore: 1秒あたりのgetmore操作数(カーソルに使用)。
  • command: 1秒あたりのコマンド操作数。
  • dirty または dirty %: メモリ内で変更されたが、まだディスクに書き込まれていないWiredTigerキャッシュデータ。正確な列名はMongoDBとツールのバージョンによって異なります。
  • used または used %: WiredTigerキャッシュ使用率。正確な列名はMongoDBとツールのバージョンによって異なります。
  • conn: 現在の接続数。
  • networkIn: サーバーが受信したネットワークトラフィック(バイト単位)。
  • networkOut: サーバーが送信したネットワークトラフィック(バイト単位)。
  • res: MongoDBプロセスが使用している常駐メモリサイズ(MB単位)。
  • qr|qw: キューに入れられた読み取りおよび書き込み操作の数(列が利用可能な場合)。
  • ar|aw: アクティブな読み取りおよび書き込みクライアントの数(列が利用可能な場合)。

mongostatの使用方法:

mongostatもコマンドラインユーティリティです。mongotopと同様に定期的に更新され、デフォルトの間隔は5秒です。別の間隔や接続詳細を指定できます。

mongostat

更新間隔を指定する場合(例:2秒ごと):

mongostat 2

リモートのMongoDBインスタンスに接続する場合:

mongostat --host <ホスト名> --port <ポート>

mongostatの出力の解釈:

  • insertqueryupdatedeleteのレートが高い: 操作負荷が高いことを示します。これらのメトリクスを他のメトリクスと一緒に監視して、システムが追いついているかどうかを理解してください。
  • connが高い: 多数の接続はサーバーリソースに負担をかける可能性があります。これが予想外に高い場合は、アプリケーションのコネクションプーリングを調査してください。
  • networkInまたはnetworkOutが高い: 大量のデータ転送を示唆します。これは、大規模なクエリ、レプリケーショントラフィック、または返される大きな結果セットが原因である可能性があります。
  • resが高い: MongoDBプロセスが大量のRAMを消費しています。サーバーに十分なメモリがあることを確認し、非効率的なクエリやメモリ使用量の増加に寄与する可能性のある大規模なデータセットがないか確認してください。
  • qr|qwが高い: 読み取りまたは書き込みがキューに入れられていることを示します。これは通常、リソースの競合や、サーバーが十分な速度で処理できないワークロードを指します。
  • dirtyまたはキャッシュusedの値が高い: WiredTigerキャッシュのプレッシャーが高いままの場合、ワーキングセットがメモリに快適に収まっていないか、ディスクへの書き込みが遅れている可能性があります。
  • 操作レートが低いのにクエリが遅い: プロファイラー、スロークエリログ、またはexplain()を使用して、クエリが過剰な数のドキュメントをスキャンしていないか確認してください。最近のmongostatの出力では、WiredTigerデプロイメントのインデックスミス率を単一のパーセンテージで確実に公開することはありません。

実用的なユースケースとトラブルシューティングシナリオ

シナリオ1: アプリケーションのパフォーマンス低下

  1. mongostatを実行: qrawinsertqueryupdatedeleteのレートを観察します。qrawが高い場合、または操作レートが高いのに処理が速く進んでいないように見える場合は、バックログを示しています。
  2. mongotopを実行: どのコレクションでread mswrite msが最も発生しているかを特定します。書き込みアクティビティが多いコレクションは、他の操作を遅くしている可能性があります。
  3. クエリプランを確認: mongotopで特定されたホットコレクションについて、代表的な遅いクエリに対してexplain("executionStats")を実行します。
  4. mongostatnetworkIn/networkOutを分析: 異常に高い場合は、大きな結果セット、大規模な集計、またはレプリケーショントラフィックがないか確認します。

シナリオ2: CPUまたはメモリ使用率が高い

  1. mongostatを実行: res(常駐メモリ)とCPU使用率(多くの場合tophtopなどのシステムツールで観察可能ですが、mongostatはDB固有の視点を提供します)を監視します。高いresは、wiredTigerキャッシュ(used %)と相関している可能性があります。
  2. mongotopを調査: 特定のコレクションでの高い読み取り/書き込みmsは、高いCPU使用率の一因となる可能性があります。
  3. mongostatの操作レートを確認: 挿入/更新/削除が非常に多い場合、これは当然CPUを消費します。
  4. WiredTigerキャッシュとディスクメトリクスを調査: アプリケーションの書き込みが遅くなる一方でダーティキャッシュが高いままの場合、MongoDBの出力をホストのディスクレイテンシとI/O飽和と比較します。

シナリオ3: レプリケーションラグ

mongotopmongostatはレプリケーションラグを直接測定しませんが、ラグの原因を理解するために重要です。

  1. プライマリでmongostatを実行: 高いqraw、高い書き込み操作レート、または高いCPU/メモリ使用率を探します。プライマリが過負荷の場合、oplogへの効率的な書き込みができず、セカンダリでラグが発生します。
  2. セカンダリでmongostatを実行: その読み取り/書き込み操作を観察します。セカンダリがoplogエントリの適用に時間がかかっている場合、セカンダリのリソース不足や、適用されている非効率的なクエリ/操作が原因である可能性があります。

ヒントとベストプラクティス

  • ツールを定期的に実行: パフォーマンスの問題が発生するのを待たないでください。MongoDBインスタンスを積極的に監視しましょう。
  • ベースラインを確立: デプロイメントの「通常」の状態を理解します。これにより、逸脱を簡単に発見できます。
  • 他のツールと組み合わせる: mongotopmongostatはリアルタイムのスナップショットに最適です。履歴分析には、MongoDBの組み込みパフォーマンス監視(例:db.serverStatus()db.stats())や、PrometheusとMongoDB Exporter、クラウドプロバイダーの監視サービスなどの外部ツールの使用を検討してください。
  • ワーキングセットを理解: アクティブなデータセットのサイズを知ることは、メモリ管理とWiredTigerキャッシュの効果を理解するために重要です。
  • クエリプランに焦点を当てる: explain("executionStats")とスロークエリログを使用して、インデックスの欠如や非効率なインデックスがスキャンを引き起こしているかどうかを確認します。
  • コネクションプーリングを検討: 高いconn数は、多くの場合、アプリケーション層で適切なコネクションプーリングを実装することで軽減できます。

まとめ

mongostatを使用してサーバーレベルのプレッシャーを理解し、mongotopを使用して最も読み取りまたは書き込みの注目を集めているコレクションを見つけます。どちらかのツールがホットな領域を指し示した場合、インデックスを変更したりデプロイメントをスケーリングしたりする前に、クエリプラン、スロークエリログ、ホストメトリクス、アプリケーションの接続動作で原因を確認してください。