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

データベースプロファイラーの出力

項目一覧

  • 出力フィールド
  • system.profile ドキュメントの例

データベースプロファイラーは、読み取り操作、書込み(write)操作、カーソル操作、データベースコマンドに関するデータ情報を取得します。データベース プロファイルを構成し、プロファイル データを取得するためのしきい値を設定する方法については、「データベースプロファイラー」セクションを参照してください。

データベースプロファイラーは、上限付きコレクションである system.profile コレクションにデータを書込みます。プロファイラーの出力を表示するには、system.profile コレクションで通常の MongoDB クエリを使用します。

注意

データベースプロファイラーはデータベース内の system.profile コレクションにデータを書込むため、読み取り専用のデータベースであっても、一部の書込み (write) アクティビティをプロファイルします。

currentOp とデータベースプロファイラーがCRUD操作について報告する基本的な診断情報は同じで、次のようなものがあります。

これらの操作は低速クエリのログにも含まれます。 低速クエリ ロギングの詳細については、 slowOpThresholdMsを参照してください。

Queryable Encryption を使用する場合、暗号化されたコレクションに対する CRUD 操作は system.profile コレクションから省略されます。詳しくは、「リダクション」を参照してください。

現在、トランザクション内から system.profile コレクションに対して任意の操作(読み取りなど)を行うことはできません。

警告

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

データベースプロファイラーによって作成されるドキュメントには、どの単一操作でも、次のフィールドのサブセットが含まれます。これらのドキュメントで正確にどのフィールドが選ばれるかは、操作の種類によって異なります。

注意

MongoDB のバージョンに固有の出力については、適切なバージョンの MongoDB マニュアルを参照してください。

system.profile.op

操作の種類。可能な値は次のとおりです。

  • command

  • count

  • distinct

  • geoNear

  • getMore

  • group

  • insert

  • mapReduce

  • query

  • remove

  • update

system.profile.ns

操作の対象となる名前空間。MongoDB の名前空間は、データベース、ドット(.)、コレクション名の形式をとります。

system.profile.command

この操作に関連付けられた完全なコマンドオブジェクトを含むドキュメント。

たとえば、次の出力には、 testという名前のデータベース内のitemsという名前のコレクションに対するfind操作のコマンド オブジェクトが含まれています。

"command" : {
"find" : "items",
"filter" : {
"sku" : 1403978
},
...
"$db" : "test"
}

次の出力例には、 testという名前のデータベース内のitemsという名前のコレクションで、カーソル ID 19234103609を持つ コマンドによって生成されたgetMore操作のコマンド オブジェクトが含まれています。

"command" : {
"getMore" : NumberLong("19234103609"),
"collection" : "items",
"batchSize" : 10,
...
"$db" : "test"
},

コマンド ドキュメントが 50 キロバイトを超える場合、ドキュメントの形式は次のようになります。

"command" : {
"$truncated": <string>,
"comment": <string>
}

$truncated フィールドには、ドキュメントの comment フィールド(存在する場合)を除いたドキュメントの文字列のサマリーが含まれます。サマリーが依然として 50 キロバイトを超える場合は、さらに切り捨てられ、文字列の末尾に省略記号 (...) が表示されます。

操作にコメントが渡された場合、comment フィールドが存在します。任意のデータベースコマンドにコメントを添付できます。

system.profile.originatingCommand

カーソルから次のバッチの結果を検索する "getmore" 操作の場合、originatingCommand フィールドには最初にそのカーソルを作成したコマンド オブジェクト全体が含まれます(例: find またはaggregate)。

system.profile.cursorid

querygetmore 操作によってアクセスされるカーソルの ID。

system.profile.keysExamined

操作を実行するために MongoDB がスキャンしたインデックスキーの数。

一般に、 keysExaminednreturned より大幅に高い場合、データベースは結果ドキュメントを見つけるために多くのインデックス キーをスキャンしています。クエリのパフォーマンスを向上させるには、インデックスの作成や調整を検討してください。

keysExamined は、以下のコマンドと操作で使用できます。

system.profile.docsExamined

操作を実行するために MongoDB がスキャンしたコレクション内のドキュメント数。

docsExamined は、以下のコマンドと操作で使用できます。

system.profile.hasSortStage

hasSortStage はブール値で、クエリがインデックス内の順序を使用して、要求されたソート結果を返すことができない場合に true になります。つまり、MongoDB は、カーソルからドキュメントを受け取った後、ドキュメントをソートする必要があります。このフィールドが表示されるのは、値が true のときだけです。

hasSortStage は、以下のコマンドと操作で使用できます。

system.profile.usedDisk

メモリ制限が原因で、集計段階で一時ファイルにデータが書込み (write) されたかどうかを示すブール値。

usedDisk が true の場合にのみ表示されます。

system.profile.ndeleted

操作によって削除されたドキュメントの数。

system.profile.ninserted

操作によって挿入されたドキュメントの数。

system.profile.nMatched

更新操作のクエリ条件に一致するドキュメントの数。

system.profile.nModified

更新操作によって変更されたドキュメントの数。

system.profile.upsert

更新操作の upsert オプション値を示すブール値。upsert が true の場合にのみ表示されます。

system.profile.fromMultiPlanner

クエリ プランナーがクエリの最適な実行プランを選択する前に複数のプランを評価したかどうかを示すブール値。

値が true の場合にのみ存在します。

system.profile.replanned

クエリシステムがキャッシュされたプランをエビクションし、すべての候補プランを再評価したかどうかを示すブール値。

値が true の場合にのみ存在します。

system.profile.replanReason

キャッシュされたプランがエビクションされた具体的な理由を示す文字列。

replanned の値が true の場合にのみ存在します。

system.profile.keysInserted

特定の書込み (write) 操作に挿入されたインデックス キーの数。

system.profile.writeConflicts

書込み (write) 操作中に発生した競合の数。たとえば、update 操作が別の update 操作と同じドキュメントを変更しようとした場合などです。書込み競合 (write conflict) も参照してください。

system.profile.numYield

他の操作を完了させるために操作が中断した回数。通常、MongoDB がまだ完全にメモリに読み込んでいないデータにアクセスする必要がある場合、操作は中断します。これにより、MongoDB が中断された操作のデータを読み込んでいる間に、メモリにデータがある他の操作を完了できます。詳しくは、操作が中断されるタイミングに関する FAQ を参照してください。

system.profile.queryHash

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

system.profile.queryShapeHash

バージョン8.0の新機能

queryShapeHash は、string クエリシェイプ のハッシュを含む 16 進数の です。詳細については、「クエリシェイプ 」を参照してください。

system.profile.planCacheShapeHash

プランキャッシュクエリシェイプのハッシュを表す16進数の文字列で、プランキャッシュクエリシェイプにのみ依存します。planCacheShapeHash は、書き込み操作のクエリフィルターなど、プランキャッシュクエリシェイプが同じで、遅いクエリを識別するのに役立ちます。

注意

他のハッシュ関数と同様に、2 つの異なるプランキャッシュクエリシェイプで同じハッシュ値が生成される場合があります。ただし、異なるプランキャッシュクエリシェイプ間でハッシュ衝突が発生する可能性は低くなります。

planCacheShapeHashplanCacheKey の詳細については、planCacheShapeHash と planCacheKey を参照してください。

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

system.profile.planCacheKey

クエリに関連付けられたプラン キャッシュ エントリのキーのハッシュです。

planCacheShapeHash とは異なり、planCacheKey は、プランキャッシュクエリシェイプと、そのシェイプに対して現在使用可能なインデックスの両方の関数です。具体的には、クエリシェイプをサポートできるインデックスを追加または削除すると、planCacheKey の値は変更される可能性がありますが、planCacheShapeHash は変更されません。

planCacheShapeHashplanCacheKey の詳細については、planCacheShapeHash と planCacheKey を参照してください。

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

system.profile.queryFramework

操作の処理に使用されるクエリフレームワーク

system.profile.locks

system.profile.locksは、操作中に保持されるさまざまなロック タイプとロック モードに関する情報を提供します。

使用可能なロック タイプは、以下のとおりです。

ロック タイプ
説明
ParallelBatchWriterMode

並列バッチ書込みモードのロックを表します。

以前のバージョンでは、PBWM 情報は Global ロック情報の一部として報告されていました。

ReplicationStateTransition
レプリカセットの状態遷移に対して取得されたロックを表します。
Global
グローバル ロックを表します。
Database
データベース ロックを表します。
Collection
コレクション ロックを表します。
Mutex
ミューテックスを表します。
Metadata
メタデータ ロックを表します。
DDLDatabase

DDLデータベース ロックを表します。

バージョン 7.1 で追加

DDLCollection

DDLコレクション ロックを表します。

バージョン 7.1 で追加

oplog
oplog のロックを表します。

ロック タイプで使用可能なロック モードは次のとおりです。

ロックモード
説明
R
共有ロック(S)を表します。
W
排他ロック(X)を表します。
r
インテント共有ロック(IS)を表します。
w
インテント排他ロック(IX)を表します。

さまざまなロック タイプに対して返されるロック情報には、次のものが含まれます。

system.profile.locks.acquireCount

操作が指定モードでロックを取得した回数。

system.profile.locks.acquireWaitCount

ロックが競合モードで保持されていたために操作がacquireCountロックの取得を待機しなければならなかった回数。 acquireWaitCountacquireCountより小さいです。

system.profile.locks.timeAcquiringMicros

操作がロックを取得するために待機しなければならなかった累計時間(マイクロ秒単位)。

timeAcquiringMicrosacquireWaitCount で割ると、特定のロック モードのおおよその平均待機時間が得られます。

system.profile.locks.deadlockCount

ロック取得を待機中に操作でデッドロックが発生した回数。

ロック モードの詳細については、「MongoDB ではどのようなタイプのロックを使用しますか」を参照してください。

system.profile.authorization

バージョン 5.0.0 の新機能

各操作でユーザー キャッシュがアクセスされる回数。これらのメトリクスは、操作がユーザー キャッシュに少なくとも 1 回アクセスした場合にのみ表示されます。

これらのメトリクスは、低速操作ロギングまたはデータベース プロファイリングが有効になっている場合にのみ使用できます。

system.profile.authorizationdb.currentOp()の出力に含まれていません。

system.profile.authorization.startedUserCacheAcquisitionAttempts

操作がユーザー キャッシュへのアクセスを試行した回数。

system.profile.authorization.completedUserCacheAcquisitionAttempts

操作によってユーザー キャッシュからユーザー データが検索された回数。

system.profile.authorization.userCacheWaitTimeMicros

操作がユーザー キャッシュの応答を待つのに費やした合計時間。

system.profile.storage

system.profile.storage の情報は、storage engine データと操作の待機時間に関するメトリクスを提供します。

特定のストレージ メトリクスは、値が 0 より大きい場合にのみ返されます。

system.profile.storage.data.bytesRead

操作によってディスクからキャッシュに読み取られたバイト数。

ディスクからキャッシュに読み込まれるデータには、クエリの実行に必要なものがすべて含まれています。データがすでにキャッシュにある場合、ディスクから読み込まれるバイト数は 0 になる可能性があります。

ディスクから読み取られるバイト数には、クエリされたドキュメント以上のものが含まれます。

  • WiredTiger はページ単位で読み取り、ページには 1 つまたは複数のドキュメントが含まれる場合があります。ドキュメントがページ内にある場合、そのページのすべてのドキュメントがキャッシュに読み込まれ、bytesRead の値に含められます。

  • キャッシュにページ管理(エビクションや再読み込みなど)が必要な場合、bytesRead の値にはこれらの操作でディスクから読み取られたデータが含まれます。

  • インデックスがキャッシュにない場合、またはキャッシュ内のインデックスが古い場合、WiredTigerはディスクからいくつかの内部ページとリーフ ページを読み取って、キャッシュ内のインデックスを再構築します。

system.profile.storage.data.timeReadingMicros

操作がディスクからの読み取りに要した時間(マイクロ秒単位)。

system.profile.storage.data.bytesWritten

操作によってキャッシュからディスクに書込まれたバイト数。

WiredTiger では通常、ディスクに書き込むクエリは必要ありません。クエリによって変更されたデータは、メモリ内キャッシュに書き込まれ、WiredTiger はエビクションまたはチェックポイント操作の一部としてディスクにフラッシュします。このような場合、bytesWritten は 0 と表示されます。

クエリを実行中のスレッドが強制的なページ管理(エビクションなど)を必要とする場合、WiredTiger はページの内容をディスクに書込みます。このフラッシュには、クエリ自体による変更とは無関係なデータが含まれる可能性が高く、bytesWritten が予想よりも高い値を示すことがあります。

system.profile.storage.data.timeWritingMicros

操作がディスクへの書込み (write) に要した時間(マイクロ秒単位)。

system.profile.storage.timeWaitingMicros.cache

操作がキャッシュ内のスペースを待機しなければならなかった時間(マイクロ秒単位)。

system.profile.storage.timeWaitingMicros.schemaLock

操作 (スキーマを変更した場合) がスキーマ ロックを取得するまで待機しなければならなかった時間(マイクロ秒単位)。

system.profile.storage.timeWaitingMicros.handleLock

操作が必要なデータ ハンドルのロックを取得するために待機しなければならなかった時間(マイクロ秒単位)。

system.profile.nreturned

操作によって返されたドキュメントの数。

system.profile.responseLength

操作の結果ドキュメントの長さ(バイト単位)。responseLength が大きいとパフォーマンスに影響する可能性があります。クエリ操作の結果ドキュメントのサイズを制限するには、次のいずれかを使用できます。

注意

MongoDB がクエリ プロファイル情報をログに書込むとき、responseLengthの値は reslen という名前のフィールドにあります。

system.profile.cpuNanos

バージョン 6.3 で追加

クエリ操作に費やされたCPU時間の合計(ナノ秒単位)。このフィールドは、Linux システムでのみ使用できます。

system.profile.protocol

MongoDB ワイヤプロトコルのリクエスト メッセージ形式。

system.profile.millis

mongodの観点から見た、操作の開始から終了までの時間(ミリ秒単位)。

planningTimeMicros

バージョン 6.2 の新機能

find コマンドまたは aggregate コマンドがクエリ プラン作成に費やした時間 (マイクロ秒単位)。

system.profile.planSummary

実行プランの概要。

system.profile.execStats

クエリ操作の実行統計を含むドキュメント。その他の操作の場合、値は空のドキュメントです。

system.profile.execStats により統計情報はツリー形式で表示されます。クエリ操作の各段階で実行された操作に関する統計情報が、各ノードから収集されます。

注意

execStats の次のフィールド リストは、返されるフィールドがステージごとに異なるため、網羅的なものではありません。

system.profile.execStats.stage

クエリ実行の一部として実行される操作の記述名。例を以下に示します。

  • COLLSCAN 、コレクションスキャン用

  • IXSCAN 、インデックス キーのスキャン用

  • FETCH 、ドキュメント検索用

system.profile.execStats.inputStages

現在のステージの入力ステージである操作の統計情報を含む配列。

system.profile.ts

操作のタイムスタンプ。

system.profile.client

操作の発信元となるクライアント接続の IP アドレスまたはホスト名。

system.profile.appName

操作を実行したクライアント・アプリケーションの識別子。 appName接続stringオプションを使用して、appName フィールドにカスタム値を設定します。

system.profile.allUsers

セッションの認証済みユーザー情報(ユーザー名とデータベース)の配列。 「自己管理型配置のユーザー 」も参照してください。

system.profile.user

操作を実行した認証済みユーザー。操作が認証済みユーザーによって実行されたものではない場合、このフィールドの値は空の文字列になります。

次の例は、system.profile コレクション内の、スタンドアロンでの操作用のサンプルドキュメントを示しています。

system.profile コレクション内の次のドキュメントは、test.report コレクションでのサンプル クエリ操作のメトリクスを示しています。

{
"op" : "query",
"ns" : "test.report",
"command" : {
"find" : "report",
"filter" : { "a" : { "$lte" : 500 } },
"lsid" : {
"id" : UUID("5ccd5b81-b023-41f3-8959-bf99ed696ce9")
},
"$db" : "test"
},
"cursorid" : 33629063128,
"keysExamined" : 101,
"docsExamined" : 101,
"fromMultiPlanner" : true,
"numYield" : 2,
"nreturned" : 101,
"planCacheShapeHash" : "811451DD",
"planCacheKey" : "759981BA",
"queryFramework" : "classic",
"locks" : {
"Global" : {
"acquireCount" : {
"r" : NumberLong(3),
"w" : NumberLong(3)
}
},
"Database" : {
"acquireCount" : { "r" : NumberLong(3) },
"acquireWaitCount" : { "r" : NumberLong(1) },
"timeAcquiringMicros" : { "r" : NumberLong(69130694) }
},
"Collection" : {
"acquireCount" : { "r" : NumberLong(3) }
}
},
"storage" : {
"data" : {
"bytesRead" : NumberLong(14736),
"timeReadingMicros" : NumberLong(17)
}
},
"responseLength" : 1305014,
"protocol" : "op_msg",
"millis" : 69132,
"planningTimeMicros" : 129,
"planSummary" : "IXSCAN { a: 1, _id: -1 }",
"execStats" : {
"stage" : "FETCH",
"nReturned" : 101,
"executionTimeMillisEstimate" : 0,
"works" : 101,
"advanced" : 101,
"needTime" : 0,
"needYield" : 0,
"saveState" : 3,
"restoreState" : 2,
"isEOF" : 0,
"docsExamined" : 101,
"alreadyHasObj" : 0,
"inputStage" : {
...
}
},
"ts" : ISODate("2019-01-14T16:57:33.450Z"),
"client" : "127.0.0.1",
"appName" : "MongoDB Shell",
"allUsers" : [
{
"user" : "someuser",
"db" : "admin"
}
],
"user" : "someuser@admin"
}

system.profile コレクションには、getMore 操作のメトリクスが含まれています。この例では、getMoretest.report コレクションから追加のドキュメントを返します。

{
"op" : "getmore",
"ns" : "test.report",
"command" : {
"getMore" : Long("33629063128"),
"collection" : "report",
"batchSize": 3,
"lsid" : {
"id": new UUID("3148c569-425c-4498-9168-5b7ee260bf27")
},
"$db" : "test"
},
originatingCommand: {
"find: "report",
"filter" : { "a" : { "$lte" : 500 } },
"lsid" : {
"id" : UUID("5ccd5b81-b023-41f3-8959-bf99ed696ce9")
},
"$db" : "test"
},
"cursorid" : Long("33629063128"),
"keysExamined" : 101,
"docsExamined" : 101,
"fromMultiPlanner" : true,
"numYield" : 2,
"nreturned" : 3,
"planCacheShapeHash" : "811451DD",
"planCacheKey" : "759981BA",
"queryFramework": "classic"
"locks" : {
"Global" : {
"acquireCount" : {
"r" : NumberLong(3),
"w" : NumberLong(3)
}
},
"Database" : {
"acquireCount" : { "r" : NumberLong(3) },
"acquireWaitCount" : { "r" : NumberLong(1) },
"timeAcquiringMicros" : { "r" : NumberLong(69130694) }
},
"Collection" : {
"acquireCount" : { "r" : NumberLong(3) }
}
},
readConcern: {level: 'local', provenance: 'implicitDefault'},
"responseLength" : 1305014,
"protocol" : "op_msg",
"millis" : 69132,
"planSummary" : "IXSCAN { a: 1, _id: -1 }",
"execStats" : {
"stage" : "FETCH",
"filter" : { "a" : { "$lte" : 500 } },
"nReturned" : 101,
"executionTimeMillisEstimate" : 0,
"works" : 104,
"advanced" : 104,
"needTime" : 0,
"needYield" : 0,
"saveState" : 3,
"restoreState" : 2,
"isEOF" : 0,
"direction": 'forward',
"docsExamined" : 104
},
"ts" : ISODate("2019-01-14T16:57:33.450Z"),
"client" : "127.0.0.1",
"appName" : "MongoDB Shell",
"allUsers" : [
{
"user" : "someuser",
"db" : "admin"
}
],
"user" : "someuser@admin"
}

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

update(および delete)の操作のプロファイル エントリには、更新コマンド全体が含まれています。

system.profile コレクション内の次のドキュメントは、 test.report コレクションのサンプル更新操作のメトリクスを示しています。

{
"op" : "update",
"ns" : "test.report",
"command" : {
"q" : { },
"u" : { "$rename" : { "a" : "b" } },
"multi" : true,
"upsert" : false
},
"keysExamined" : 0,
"docsExamined" : 25000,
"nMatched" : 25000,
"nModified" : 25000,
"keysInserted" : 25000,
"keysDeleted" : 25000000,
"numYield" : 6985,
"locks" : {
"Global" : {
"acquireCount" : { "r" : NumberLong(6986), "w" : NumberLong(13972) }
},
"Database" : {
"acquireCount" : { "w" : NumberLong(6986) },
"acquireWaitCount" : { "w" : NumberLong(1) },
"timeAcquiringMicros" : { "w" : NumberLong(60899375) }
},
"Collection" : {
"acquireCount" : { "w" : NumberLong(6986) }
},
"Mutex" : {
"acquireCount" : { "r" : NumberLong(25000) }
}
},
"storage" : {
"data" : {
"bytesRead" : NumberLong(126344060),
"bytesWritten" : NumberLong(281834762),
"timeReadingMicros" : NumberLong(94549),
"timeWritingMicros" : NumberLong(139361)
}
},
"millis" : 164687,
"planningTimeMicros" : 129,
"planSummary" : "COLLSCAN",
"execStats" : {
"stage" : "UPDATE",
"nReturned" : 0,
"executionTimeMillisEstimate" : 103771,
"works" : 25003,
"advanced" : 0,
"needTime" : 25002,
"needYield" : 0,
"saveState" : 6985,
"restoreState" : 6985,
"isEOF" : 1,
"nMatched" : 25000,
"nWouldModify" : 25000,
"wouldInsert" : false,
"inputStage" : {
"stage" : "COLLSCAN",
"nReturned" : 25000,
"executionTimeMillisEstimate" : 0,
"works" : 25002,
"advanced" : 25000,
"needTime" : 1,
"needYield" : 0,
"saveState" : 31985,
"restoreState" : 31985,
"isEOF" : 1,
"direction" : "forward",
"docsExamined" : 25000
}
},
"ts" : ISODate("2019-01-14T23:33:01.806Z"),
"client" : "127.0.0.1",
"appName" : "MongoDB Shell",
"allUsers" : [
{
"user" : "someuser",
"db" : "admin"
}
],
"user" : "someuser@admin"
}

戻る

Database Profiler