Database Profiler
データベースプロファイラーは、実行中の mongod
インスタンスに対して実行されたデータベースコマンドに関する詳細情報を収集します。これには、CRUD 操作だけでなく、構成コマンドおよび管理コマンドも含まれます。
プロファイラーは、収集したすべてのデータを、プロファイリング済みデータベースそれぞれの上限付きコレクションである system.profile
コレクションに書き込みます。プロファイラーが作成する system.profile
ドキュメントの概要については、「 データベース プロファイラーの出力」を参照してください。
プロファイラーはデフォルトでoff
です。 プロファイラーは、複数のプロファイリング レベルのいずれかで、データベースごとまたはインスタンスごとに有効にできます。
プロファイリングを有効にすると、データベースのパフォーマンスとディスク使用量に影響します。 詳細については、「データベースプロファイラのオーバーヘッド」を参照してください。
このページには、データベースプロファイラーの重要な管理オプションが表示されます。詳細については、次を参照してください。
警告
system.profile
という名前の時系列コレクションまたはビューを作成しないでください。MongoDB 6.3 以降のバージョンでは、これを実行しようとするとIllegalOperation
エラーが返されます。以前のバージョンの MongoDB はクラッシュします。
プロファイリング レベル
次のプロファイリング・レベルを使用できます。
データベース プロファイリングの有効化と構成
mongod
インスタンスのデータベース プロファイリングを有効にできます。
このセクションでは、 mongosh
ヘルパーメソッドdb.setProfilingLevel()
を使用してプロファイリングを有効にする方法を説明します。代わりにドライバー メソッドを使用するには、「ドライバーのドキュメント 」を参照してください。
mongod
インスタンスのプロファイリングを有効にするには、プロファイリング レベルを0
より大きい値に設定します。 プロファイラーはsystem.profile
コレクションにデータを記録します。 MongoDB は、そのデータベースのプロファイリングを有効にすると、そのデータベースにsystem.profile
コレクションを作成します。
プロファイリングを有効にしてプロファイリング レベルを設定するには、プロファイリング レベルをdb.setProfilingLevel()
ヘルパーに渡します。 たとえば、現在接続されているデータベースのすべてのデータベース操作のプロファイリングを有効にするには、 mongosh
で次の操作を実行します。
db.setProfilingLevel(2)
shell は、was
フィールドに前のプロファイリング レベルを返し、新しいレベルを設定します。次の出力における "ok" :
1
のキーと値のペアは、操作の成功を示しています。
{ "was" : 0, "slowms" : 100, "sampleRate" : 1.0, "ok" : 1 }
新しい設定を確認するには、 「 プロファイリング レベルの確認」セクションを参照してください。
MongoDB 5.0 700} 以降では、 profile
コマンドまたはdb.setProfilingLevel()
ラッパー メソッドを使用してデータベースプロファイラーlevel
、 slowms
、 sampleRate
、またはfilter
に加えられた変更は、 log file
に記録されます。
グローバルおよびデータベースごとのプロファイリング設定
slowms および sampleRate の両プロファイリング設定はグローバルです。これらを設定すると、プロセス内のすべてのデータベースに影響します。
profile
コマンドまたはdb.setProfilingLevel()
shellヘルパー メソッドで設定すると、プロファイリング レベルとフィルター設定はデータベースレベルで設定されます。 コマンドライン オプションまたは構成ファイルオプションのいずれかとして設定すると、プロファイリング レベルとfilter
設定はプロセス全体に影響します。
低速操作のしきい値を指定
デフォルトでは、低速操作のしきい値は 100 ミリ秒です。低速操作のしきい値を変更するには、次のいずれかの方法で必要なしきい値を指定します。
profile
コマンドまたはdb.setProfilingLevel()
シェルヘルパー メソッドを使用してslowms
の値を設定します。スタートアップ時にコマンドラインから
--slowms
の値を設定します。構成ファイルで
slowOpThresholdMs
の値を設定します。
次の例では、現在接続されているデータベースのプロファイリング レベルを1
に設定し、mongod
インスタンスにおける低速操作のしきい値を 20
ミリ秒に設定します。
db.setProfilingLevel( 1, { slowms: 20 } )
プロファイリング レベルが 1
の場合、プロファイラーは slowms
のしきい値よりも遅い操作を記録します。
重要
低速操作のしきい値は mongod
インスタンスのすべてのデータベースに適用されます。この値はデータベースプロファイラーと診断ログの両方に使用されるため、パフォーマンスの低下を避けるために、最も有用な値に設定する必要があります。
db.setProfilingLevel()
を使用して、mongos
の slowms
と sampleRate
を構成できます。mongos
の場合、slowms
および sampleRate
の構成設定は診断ログにのみ影響し、プロファイラーには影響しません。プロファイリングは mongos
では使用できないためです。[1]
次の例では、低速操作のログを 20
に記録するため、mongos
インスタンスの低速操作のしきい値を設定します。
db.setProfilingLevel( 0, { slowms: 20 } )
プロファイラー エントリと読み取り操作および書込み (write ) 操作の 診断ログ メッセージ(mongod/mongos ログ メッセージなど)には次のものが含まれます。
replica setのセカンダリ メンバーは、適用に低速操作しきい値よりも長い時間がかかるoplogをログに記録するようになりました。 これらの遅い oplog メッセージ:
ログは、テキスト
applied op: <oplog entry> took <num>ms
を含むREPL
コンポーネントの下にあります。ログレベルに依存しない(システムレベルでもコンポーネントレベルでも)
プロファイル レベルに依存しないでください。
slowOpSampleRate
の影響を受けます。
プロファイラーは遅い oplog エントリをキャプチャしません。
低速操作のランダム サンプルのプロファイリング
すべての低速操作からランダムにサンプリングされたサブセットのみをプロファイリングするには、次のいずれかの方法で、必要なサンプリング レートを指定します。 [2]
profile
コマンドまたはdb.setProfilingLevel()
シェルヘルパー メソッドを使用してsampleRate
の値を設定します。スタートアップ時にコマンドラインから
mongod
の場合は--slowOpSampleRate
の値、mongos
の場合は--slowOpSampleRate
の値を設定します。構成ファイルで
slowOpSampleRate
の値を設定します。
デフォルトでは、sampleRate
は 1.0
に設定されています。つまり、すべての低速操作がプロファイリングされます。sampleRate
が 0
と 1
の間に設定されている場合、プロファイリング レベルが 1
のデータベースは、sampleRate
に基づいてランダムにサンプリングされた割合で低速操作をプロファイリングします。
次の例では、現在接続されているデータベースのプロファイリング レベルを 1
に設定し、プロファイラーがすべての低速操作の 42% をサンプリングするように設定します。
db.setProfilingLevel( 1, { sampleRate: 0.42 } )
変更されたサンプル レート値はシステム ログにも適用されます。
db.setProfilingLevel()
を使用して、mongos
の slowms
と sampleRate
を構成できます。mongos
の場合、slowms
および sampleRate
の構成設定は診断ログにのみ影響し、プロファイラーには影響しません。プロファイリングは mongos
では使用できないためです。[1]
次の例では、低速操作をログに記録するための mongos
インスタンスのサンプリング レートを設定します。
db.setProfilingLevel( 0, { sampleRate: 0.42 } )
重要
[1] | ( 1 、 2 ) 「データベース プロファイリングとシャーディング」 を参照してください。 |
プロファイルされた操作を決定するためにフィルターを設定する
どの操作をプロファイリングしてログに記録するかは、フィルターの設定で制御できます。プロファイリング フィルターは、次のいずれかの方法で設定できます。
profile
コマンドまたはdb.setProfilingLevel()
シェルヘルパー メソッドを使用してfilter
の値を設定します。
mongod
インスタンスの場合、filter
は診断ログと(有効になっている場合)プロファイラーの両方に影響します。
mongos
インスタンスの場合、filter
は診断ログにのみ影響し、プロファイラーには影響しません。プロファイリングは mongos
では使用できないためです。
注意
プロファイリングの filter
が設定されている場合、slowms および sampleRate オプションは診断ログまたはプロファイラーに影響しません。
次の db.setProfilingLevel()
の例では、現在接続されているデータベースのプロファイリング レベルを設定します。
プロファイリングレベル を
2
に設定し、{ op: "query", millis: { $gt: 2000 } }
のフィルター をかけると、プロファイラーは 2 秒以上かかったquery
操作のみをログに記録します。
db.setProfilingLevel( 2, { filter: { op: "query", millis: { $gt: 2000 } } } )
プロファイリング レベルの確認
プロファイリング レベルを表示するには、 mongosh
で次の例を実行します。
db.getProfilingStatus()
shellは、次のようなドキュメントを返します。
{ "was" : 0, "slowms" : 100, "sampleRate" : 1.0, "ok" : 1 }
was
フィールドは、現在のプロファイリング レベルを示します。
slowms
フィールドは、低速とみなされる操作時間のしきい値(ミリ秒単位)を示します。
sampleRate
フィールドは、プロファイリングするべき低速操作の割合を示します。
プロファイリングの無効化
プロファイリングを無効にするには、mongosh
で次の例を実行します。
db.setProfilingLevel(0)
注意
プロファイリングを無効にすると、データベースのパフォーマンスが向上し、ディスク使用量が削減されます。 詳細については、「データベースプロファイラのオーバーヘッド」を参照してください。
mongod
インスタンス全体のプロファイリングを有効にする
開発環境およびテスト環境では、mongod
インスタンス全体に対してデータベースのプロファイリングを有効にできます。プロファイリング レベルは、mongod
インスタンスのすべてのデータベースに適用されます。
mongod
インスタンスのプロファイリングを有効にするには、スタートアップ時に次のオプションを mongod
に渡します。
mongod --profile 1 --slowms 15 --slowOpSampleRate 0.5
または、構成ファイルで operationProfiling を指定します。
これにより、プロファイリング レベルが 1
に設定され、15
ミリ秒より長く続く操作が低速と定義され、低速操作の 50% のみをプロファイリングするように指定されます。[2]
slowms
と slowOpSampleRate
は、logLevel
が 0
に設定されている場合に診断ログに記録される操作にも影響します。slowms
と slowOpSampleRate
は、mongos
の診断ログの構成にも使用できます。[2]
データベース プロファイリングとシャーディング
mongos
インスタンスではプロファイリングを有効にできません。シャーディングされたクラスターでプロファイリングを有効にするには、クラスター内の各 mongod
インスタンスのプロファイリングを有効にする必要があります。
ただし、--slowms
と slowOpSampleRate
を mongos
で設定すると、低速操作の診断ログを構成できます。
プロファイラー データを表示
データベースプロファイラーは、データベース操作に関する情報を system.profile
コレクションに記録します。
プロファイリング情報を表示するには、 system.profile
コレクションをクエリします。 クエリの例を表示するには、「プロファイラー データ クエリの例」を参照してください。 出力データの説明については、「データベース プロファイラー出力 」を参照してください。
現在、トランザクション内から system.profile
コレクションに対して任意の操作(読み取りなど)を行うことはできません。
プロファイラーのデータ クエリの例
このセクションでは、system.profile
コレクションのクエリの例を示します。クエリ出力の詳細については、「データベースプロファイラー出力」を参照してください。
system.profile
コレクション内の直近 10 件のログ エントリを返すには、次のようなクエリを実行します。
db.system.profile.find().limit(10).sort( { ts : -1 } ).pretty()
コマンド操作($cmd)を除くすべての操作を返すには、次のようなクエリを実行します。
db.system.profile.find( { op: { $ne : 'command' } } ).pretty()
特定のコレクションの操作を返すには、次のようなクエリを実行します。この例では、 mydb
データベースの test
コレクションの操作を返します。
db.system.profile.find( { ns : 'mydb.test' } ).pretty()
完了までの時間が 5 ミリ秒を超える操作を返すには、次を実行します。
db.system.profile.find( { millis : { $gt : 5 } } ).pretty()
特定の時間範囲の操作を返すには、次を実行します。
db.system.profile.find( { ts : { $gt: new ISODate("2012-12-09T03:00:00Z"), $lt: new ISODate("2012-12-09T03:40:00Z") } } ).pretty()
次の例では、時間範囲を確認し、読みやすくするために出力の user
フィールドを非表示にして、各操作の実行時間で結果を並べ替えます。
db.system.profile.find( { ts : { $gt: new ISODate("2011-07-12T03:00:00Z"), $lt: new ISODate("2011-07-12T03:40:00Z") } }, { user: 0 } ).sort( { millis: -1 } )
最新の 5 つのイベントを表示する
プロファイリングが有効になっているデータベースでは、 mongosh
のshow profile
ヘルパーには、実行に少なくとも1ミリ秒かかった5の最新の操作が表示されます。 mongosh
show profile
を実行します。
show profile
プロファイラーのオーバーヘッド
有効にすると、プロファイリングはデータベースのパフォーマンスに影響します。特にプロファイリング レベルが2に設定されている場合、またはプロファイリング レベルが1の低しきい値を使用している場合は、データベースのパフォーマンスに影響します。
プロファイリングは、ディスク領域も使用します。ログが system.profile
コレクションと MongoDB logfile
に書き込まれるためです。
警告
プロファイラーを本番環境の配置で有効にする前に、パフォーマンスとストレージへの影響を検討してください。
コレクションsystem.profile
system.profile
コレクションは、デフォルト サイズが 1 メガバイトの上限付きコレクションです。このサイズのコレクションには通常、数千のプロファイル ドキュメントを格納できますが、アプリケーションによって、1 回の操作で使用するプロファイリング データの量は増減する場合があります。system.profile
コレクションのサイズを変更する必要がある場合、以下の手順に従ってください。
system.profile
プライマリの コレクションのサイズ変更
プライマリの system.profile
コレクションのサイズを変更する手順は以下の通りです。
プロファイリングを無効にします。
system.profile
コレクションを削除します。新しい
system.profile
コレクションを作成します。プロファイリングを再度有効にします。
たとえば、 4000000
バイト( 4 MB)の新しいsystem.profile
コレクションを作成するには、 mongosh
で次の一連の操作を使用します。
db.setProfilingLevel(0) db.system.profile.drop() db.createCollection( "system.profile", { capped: true, size:4000000 } ) db.setProfilingLevel(1)
セカンダリのsystem.profile
コレクションのサイズ変更
セカンダリ 上のsystem.profile
コレクションのサイズを変更するには、セカンダリを停止してスタンドアロンとして実行してから、上記の手順を踏む必要があります。 完了したら、そのスタンドアロンをレプリカセットのノードとして再起動します。 詳細は、「自己管理型レプリカセットのノードのメンテナンスの実行 」を参照してください。
[2] | ( 1 、 2 、 3 ) replica setのセカンダリ メンバーは、低速操作のしきい値よりも長い時間がかかるoplogをログに記録するようになりました。 これらの遅い oplog メッセージ:
|