警告
データベースプロファイラーはMongoDB のパフォーマンスを低下させる可能性があります。データベースプロファイラーを有効にする前に、次のいずれかの代替手段を使用することを検討してください。
データベースプロファイラーのパフォーマンスへの影響の詳細については、プロファイラーのオーバーヘッドを参照してください。
データベースプロファイラーは、データベースコマンドやCRUD操作、管理コマンドなど、実行中のmongodインスタンスに対して実行された詳細情報を収集します。
プロファイラーは、プロファイリング済みデータベースそれぞれのsystem.profileコレクション、つまり上限付きコレクションにデータを書き込みます。プロファイラーが作成するドキュメントの概要については、データベース プロファイラーの出力を参照してください。
プロファイラーはデフォルトで off です。これは、複数のプロファイリング レベルのいずれかで、データベースごとまたはインスタンスごとに有効にできます。有効にすると、プロファイリングはデータベースのパフォーマンスとディスク使用量に影響します。詳しくは、データベース プロファイラーのオーバーヘッド を参照してください。
このページには、重要なデータベースプロファイラ管理オプションが記載されています。詳細については、次を参照してください。
プロファイリング レベル
次のプロファイリング・レベルを使用できます。
0- プロファイラーはオフになっており、データは収集されません。これはデフォルトのプロファイラー レベルです。
1プロファイラーは、
slowmsしきい値を超える操作、または指定されたフィルターに一致する操作のデータを収集します。フィルターが設定されている場合、
slowmsおよびsampleRateオプションはプロファイリングには使用されません。プロファイラーは、フィルターに一致する操作のみをキャプチャします。
2プロファイラーは、すべての操作のデータを収集します。
レベル
2に設定すると、プロファイラーはslowmsとfilterのユーザーが指定した値を無視します。
データベース プロファイリングの有効化と構成
mongod インスタンスのデータベース プロファイリングを有効にできます。
プロファイリングを有効にするには、次のいずれかの方法を使用します。
スタートアップ時にプロファイリングを有効にするには、
operationProfiling.modeを構成ファイルに設定します。実行時にプロファイリングを有効にするには、
mongoshヘルパーメソッドdb.setProfilingLevel()を使用します。ドライバーでプロファイリングを有効にするには、ドライバー メソッドを使用します。
MongoDB は、データベースのプロファイリングを有効にすると、そのデータベースに system.profile コレクションを作成します。プロファイラーはこのコレクションを使用してデータをレコード。
起動時に mongod インスタンスのプロファイリングを有効にするには、operationProfiling.mode を構成ファイルで目的のログレベルに設定します。
現在接続されているデータベースに対するすべての操作のプロファイリングを有効にするには、mongosh: で を実行します。
db.setProfilingLevel(2)
The shell returns the 前のプロファイリング レベルを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()で設定するとデータベースレベルの設定になります。コマンドライン オプションまたは構成ファイルオプションとして設定すると、 プロセス全体に影響します。
低速操作のしきい値を指定
デフォルトでは、低速操作のしきい値は 100 ミリ秒です。
低速操作は、MongoDB でその操作にかかった時間である workingMillis に基づいてログに記録されます。つまり、ロック待ちやフロー制御などの要因は、操作が低速操作のしきい値を超えるかどうかに影響しません。
低速操作のしきい値を変更するには、次のいずれかを使用します。
profileコマンドまたはdb.setProfilingLevel()シェルヘルパー メソッドを使用してslowmsの値を設定します。スタートアップ時にコマンドラインから
--slowmsの値を設定します。構成ファイルで
slowOpThresholdMsの値を設定します。
次の例では、現在接続されているデータベースのプロファイリング レベルを1 に設定し、mongod インスタンスにおける低速操作のしきい値を 20 ミリ秒に設定します。
db.setProfilingLevel( 1, { slowms: 20 } )
プロファイリング レベルが 1 の場合、プロファイラーは slowms のしきい値よりも遅い操作を記録します。
重要
低速操作しきい値は、mongodインスタンス内のすべてのデータベースに適用されます。これは、データベースプロファイラーと 診断ログ の両方に使用されます。パフォーマンスの低下を避けるために、最も有用な値に設定してください。
mongos の場合、db.setProfilingLevel() を使用して slowms と sampleRate を構成します。これらの設定はプロファイラーではなく、mongos の診断ログにのみ影響します。プロファイリングは mongos では利用できません。[1]
次の例では、低速操作のログを 20 に記録するため、mongos インスタンスの低速操作のしきい値を設定します。
db.setProfilingLevel( 0, { slowms: 20 } )
プロファイラー エントリと読み取り操作および書込み (write ) 操作の 診断ログ メッセージ(mongod/mongos ログ メッセージなど)には次のものが含まれます。
planCacheShapeHashプランキャッシュクエリシェイプが同じスロークエリを特定するのに役立ちます。MongoDB 8.0 以降では、既存の
queryHashフィールドはplanCacheShapeHashという名前の新しいフィールドに重複します。 以前のバージョンのMongoDBを使用している場合は、queryHashフィールドのみが表示されます。 今後のMongoDBバージョンでは、非推奨のqueryHashフィールドが排除されます。代わりにplanCacheShapeHashフィールドを使用する必要があります。planCacheKey低速クエリのクエリプラン キャッシュに関する詳細なインサイトを提供します。
replica setのセカンダリ メンバーは、適用に低速操作しきい値よりも長い時間がかかるoplogをログに記録するようになりました。 これらの遅い oplog メッセージ:
ログは、テキスト
applied op: <oplog entry> took <num>msを含むREPLコンポーネントの下にあります。ログレベルに依存しない(システムレベルでもコンポーネントレベルでも)
プロファイル レベルに依存しないでください。
slowOpSampleRateの影響を受けます。
プロファイラーは遅い oplog エントリをキャプチャしません。
低速操作のランダム サンプルのプロファイリング
低速操作のランダムにサンプリングされたサブセットのみをプロファイリングするには、次のいずれかの方法で sampleRateを設定します。 []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 } )
変更されたサンプル レート値はシステム ログにも適用されます。
mongos の場合、slowms と sampleRate は 診断ログのみに影響し、プロファイラー には影響しません。[]1 mongosロギングのサンプリング レートを設定するには、次の手順に従います。
db.setProfilingLevel( 0, { sampleRate: 0.42 } )
重要
| [1] | ( 1 、 2 ) 「データベース プロファイリングとシャーディング」 を参照してください。 |
プロファイルされた操作を決定するためにフィルターを設定する
どの操作をプロファイリングしてログに記録するかを制御するには、次のいずれかの方法でフィルターを設定します。
profileコマンドまたはdb.setProfilingLevel()。
mongod の場合、filter は有効になっている場合、診断ログとプロファイラー の両方に影響します。mongos の場合、filter は診断ログにのみ影響します。
注意
プロファイリングの filter が設定されている場合、slowms および sampleRate オプションは診断ログまたはプロファイラーに影響しません。
次の例では、2 秒以上かかる query 操作のみをログに記録するフィルターで、プロファイリング レベル 1 を設定します。
db.setProfilingLevel( 1, { 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 --profile 1 --slowms 15 --slowOpSampleRate 0.5
または、operationProfiling を構成ファイルで指定します。
これにより、プロファイリング レベルが 1 に設定され、15 ミリ秒より長く続く操作が低速と定義され、 低速 操作の 50% がプロファイリングされます。[2]
slowms と slowOpSampleRate も、logLevel が 0 の場合に診断ログに記録される操作に影響します。どちらの設定も mongos の診断ログも構成します。[2]
データベース プロファイリングとシャーディング
インスタンスではプロファイリングを有効に できませんmongos 。シャーディングされたクラスターでプロファイリングを有効にするには、クラスター内の各 mongod インスタンスで有効にします。
低速操作の診断ログを構成するには、--slowms と slowOpSampleRate を mongos で設定できます。
プロファイラー データを表示
プロファイラーはデータベース操作を 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 の低 slowms しきい値を使用している場合に、データベースのパフォーマンスに影響します。プロファイリングは、ディスク領域も使用します。これは system.profile コレクションとMongoDB logfile に書き込まれるためです。
警告
プロファイラーを本番環境の配置で有効にする前に、パフォーマンスとストレージへの影響を検討してください。
system.profile コレクション
system.profileコレクションは、デフォルトサイズが 1 メガバイトの上限付きコレクションで、通常数千のプロファイル ドキュメントを保存できます。サイズを変更する必要がある場合、以下の手順に従ってください。
プライマリの system.profile コレクションのサイズ変更
プライマリのsystem.profileコレクションのサイズを変更するには:
プロファイリングを無効にします。
system.profileコレクションを削除します。新しい
system.profileコレクションを作成します。プロファイリングを再度有効にします。
system.profile4000000例、:4mongosh に バイト( MB)の新しい コレクションを作成するには、次のようにします。
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 メッセージ:
|