Docs Menu
Docs Home
/
MongoDBマニュアル
/ / / /

Database Profiler

項目一覧

  • プロファイリング レベル
  • データベース プロファイリングの有効化と構成
  • プロファイラー データを表示
  • プロファイラーのオーバーヘッド

データベースプロファイラーは、実行中の mongod インスタンスに対して実行されたデータベースコマンドに関する詳細情報を収集します。これには、CRUD 操作だけでなく、構成コマンドおよび管理コマンドも含まれます。

プロファイラーは、収集したすべてのデータを、プロファイリング済みデータベースそれぞれの上限付きコレクションである system.profile コレクションに書き込みます。プロファイラーが作成する system.profile ドキュメントの概要については、「 データベース プロファイラーの出力」を参照してください。

プロファイラーはデフォルトでoffです。 プロファイラーは、複数のプロファイリング レベルのいずれかで、データベースごとまたはインスタンスごとに有効にできます。

プロファイリングを有効にすると、データベースのパフォーマンスとディスク使用量に影響します。 詳細については、「データベースプロファイラのオーバーヘッド」を参照してください。

このページには、データベースプロファイラーの重要な管理オプションが表示されます。詳細については、次を参照してください。

警告

system.profile という名前の時系列コレクションまたはビューを作成しないでください。MongoDB 6.3 以降のバージョンでは、これを実行しようとするとIllegalOperationエラーが返されます。以前のバージョンの MongoDB はクラッシュします。

次のプロファイリング・レベルを使用できます。

0
プロファイラーはオフになっており、データは収集されません。これはデフォルトのプロファイラー レベルです。
1

プロファイラーは、 slowmsしきい値を超える操作、または指定されたフィルターに一致する操作のデータを収集します。

フィルターが設定されている場合、

  • slowmsおよびsampleRateオプションはプロファイリングには使用されません。

  • プロファイラーは、フィルターに一致する操作のみをキャプチャします。

2
プロファイラーは、すべての操作のデータを収集します。

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()ラッパー メソッドを使用してデータベースプロファイラーlevelslowmssampleRate 、またはfilterに加えられた変更は、 log fileに記録されます。

slowms および sampleRate の両プロファイリング設定はグローバルです。これらを設定すると、プロセス内のすべてのデータベースに影響します。

profileコマンドまたはdb.setProfilingLevel() shellヘルパー メソッドで設定すると、プロファイリング レベルフィルター設定はデータベースレベルで設定されます。 コマンドライン オプションまたは構成ファイルオプションのいずれかとして設定すると、プロファイリング レベルとfilter設定はプロセス全体に影響します。

デフォルトでは、低速操作のしきい値は 100 ミリ秒です。

低速操作は、MongoDB でその操作にかかった時間である workingMillis に基づいてログに記録されます。つまり、ロック待ちやフロー制御などの要因は、操作が低速操作のしきい値を超えるかどうかに影響しません。

低速操作のしきい値を変更するには、次のいずれかの方法で必要なしきい値を指定します。

次の例では、現在接続されているデータベースのプロファイリング レベルを1 に設定し、mongod インスタンスにおける低速操作のしきい値を 20 ミリ秒に設定します。

db.setProfilingLevel( 1, { slowms: 20 } )

プロファイリング レベルが 1 の場合、プロファイラーは slowms のしきい値よりも遅い操作を記録します。

重要

低速操作のしきい値は mongod インスタンスのすべてのデータベースに適用されます。この値はデータベースプロファイラーと診断ログの両方に使用されるため、パフォーマンスの低下を避けるために、最も有用な値に設定する必要があります。

db.setProfilingLevel() を使用して、mongosslowmssampleRate を構成できます。mongos の場合、slowms および sampleRate の構成設定は診断ログにのみ影響し、プロファイラーには影響しません。プロファイリングは mongos では使用できないためです。[1]

次の例では、低速操作のログを 20 に記録するため、mongos インスタンスの低速操作のしきい値を設定します。

db.setProfilingLevel( 0, { slowms: 20 } )

プロファイラー エントリと読み取り操作および書込み (write ) 操作の 診断ログ メッセージ(mongod/mongos ログ メッセージなど)には次のものが含まれます。

  • planCacheShapeHash プランキャッシュクエリシェイプが同じスロークエリを特定するのに役立ちます。

    MongoDB 8.0以降、既存のqueryHashフィールドの名前がplanCacheShapeHashに変更されます。 以前のバージョンの MongoDB を使用している場合は、 planCacheShapeHashではなくqueryHashが表示されます。

  • planCacheKey 低速クエリのクエリプラン キャッシュに関する詳細なインサイトを提供します。

replica setのセカンダリ メンバーは、適用に低速操作しきい値よりも長い時間がかかるoplogをログに記録するようになりました。 これらの遅い oplog メッセージ:

プロファイラーは遅い oplog エントリをキャプチャしません。

すべての低速操作からランダムにサンプリングされたサブセットのみをプロファイリングするには、次のいずれかの方法で、必要なサンプリング レートを指定します。 [2]

デフォルトでは、sampleRate1.0 に設定されています。つまり、すべての低速操作がプロファイリングされます。sampleRate01 の間に設定されている場合、プロファイリング レベルが 1 のデータベースは、sampleRate に基づいてランダムにサンプリングされた割合で低速操作をプロファイリングします。

次の例では、現在接続されているデータベースのプロファイリング レベルを 1 に設定し、プロファイラーがすべての低速操作の 42% をサンプリングするように設定します。

db.setProfilingLevel( 1, { sampleRate: 0.42 } )

変更されたサンプル レート値はシステム ログにも適用されます。

db.setProfilingLevel() を使用して、mongosslowmssampleRate を構成できます。mongos の場合、slowms および sampleRate の構成設定は診断ログにのみ影響し、プロファイラーには影響しません。プロファイリングは mongos では使用できないためです。[1]

次の例では、低速操作をログに記録するための mongos インスタンスのサンプリング レートを設定します。

db.setProfilingLevel( 0, { sampleRate: 0.42 } )

重要

logLevel0に設定されている場合、MongoDB は slowOpSampleRate で決定されたレートで低速操作を診断ログに記録します

logLevel 設定を引き上げると、レイテンシに関係なく、すべての操作が診断ログに表示されます。ただし、セカンダリによる低速の oplog エントリ メッセージのログ記録は除きます。セカンダリでは、低速の oplog エントリのみがログに記録されます。logLevel を引き上げても、すべての oplog エントリがログに記録されるわけではありません。

[1]12データベース プロファイリングとシャーディング」 を参照してください。

どの操作をプロファイリングしてログに記録するかは、フィルターの設定で制御できます。プロファイリング フィルターは、次のいずれかの方法で設定できます。

mongod インスタンスの場合、filter は診断ログと(有効になっている場合)プロファイラーの両方に影響します。

mongos インスタンスの場合、filter は診断ログにのみ影響し、プロファイラーには影響しません。プロファイリングは mongosでは使用できないためです。

注意

プロファイリングの filter が設定されている場合、slowms および sampleRate オプションは診断ログまたはプロファイラーに影響しません。

次の db.setProfilingLevel() の例では、現在接続されているデータベースのプロファイリング レベルを設定します。

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 --profile 1 --slowms 15 --slowOpSampleRate 0.5

または、構成ファイルoperationProfiling を指定します。

これにより、プロファイリング レベルが 1 に設定され、15 ミリ秒より長く続く操作が低速と定義され、低速操作の 50% のみをプロファイリングするように指定されます。[2]

slowmsslowOpSampleRate は、logLevel0 に設定されている場合に診断ログに記録される操作にも影響します。slowmsslowOpSampleRate は、mongos の診断ログの構成にも使用できます。[2]

Tip

以下も参照してください。

mongos インスタンスではプロファイリングを有効にできません。シャーディングされたクラスターでプロファイリングを有効にするには、クラスター内の各 mongod インスタンスのプロファイリングを有効にする必要があります。

ただし、--slowmsslowOpSampleRatemongos で設定すると、低速操作の診断ログを構成できます。

データベースプロファイラーは、データベース操作に関する情報を 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 } )

プロファイリングが有効になっているデータベースでは、 mongoshshow profileヘルパーには、実行に少なくとも1ミリ秒かかった5の最新の操作が表示されます。 mongosh show profileを実行します。

show profile

有効にすると、プロファイリングはデータベースのパフォーマンスに影響します。特にプロファイリング レベルが2に設定されている場合、またはプロファイリング レベルが1の低しきい値を使用している場合は、データベースのパフォーマンスに影響します。

プロファイリングは、ディスク領域も使用します。ログが system.profile コレクションと MongoDB logfile に書き込まれるためです。

警告

プロファイラーを本番環境の配置で有効にする前に、パフォーマンスとストレージへの影響を検討してください。

system.profile コレクションは、デフォルト サイズが 1 メガバイトの上限付きコレクションです。このサイズのコレクションには通常、数千のプロファイル ドキュメントを格納できますが、アプリケーションによって、1 回の操作で使用するプロファイリング データの量は増減する場合があります。system.profile コレクションのサイズを変更する必要がある場合、以下の手順に従ってください。

プライマリsystem.profile コレクションのサイズを変更する手順は以下の通りです。

  1. プロファイリングを無効にします。

  2. system.profile コレクションを削除します。

  3. 新しいsystem.profile コレクションを作成します。

  4. プロファイリングを再度有効にします。

たとえば、 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コレクションのサイズを変更するには、セカンダリを停止してスタンドアロンとして実行してから、上記の手順を踏む必要があります。 完了したら、そのスタンドアロンをレプリカセットのノードとして再起動します。 詳細は、「自己管理型レプリカセットのノードのメンテナンスの実行 」を参照してください。

[2]( 123 ) replica setのセカンダリ メンバーは、低速操作のしきい値よりも長い時間がかかるoplogをログに記録するようになりました。 これらの遅い oplog メッセージ:プロファイラーは遅い oplog エントリをキャプチャしません。

戻る

結果の解釈