データベースプロファイラーの出力
データベースプロファイラーは、読み取り操作、書込み（write）操作、カーソル操作、データベースコマンドに関するデータ情報を取得します。データベース プロファイルを構成し、プロファイル データを取得するためのしきい値を設定する方法については、「データベースプロファイラー」セクションを参照してください。
データベースプロファイラーは、上限付きコレクションである system.profile コレクションにデータを書込みます。プロファイラーの出力を表示するには、system.profile コレクションで通常の MongoDB クエリを使用します。
注意
データベースプロファイラーはデータベース内のsystem.profileコレクションにデータを書込むため、読み取り専用のデータベースであっても、一部の書込み (write) アクティビティをプロファイルします。
currentOpとデータベースプロファイラーが報告する基本的なCRUD情報は同じで、次のようなものがあります。
getMore（OP_GET_MORE とcommand）
これらの操作は低速クエリのログにも含まれます。 低速クエリ ロギングの詳細については、 slowOpThresholdMsを参照してください。
現在、トランザクション内から system.profile コレクションに対して任意の操作（読み取りなど）を行うことはできません。
警告
MongoDB サーバーがクラッシュするため、 system.profileという名前の時系列コレクションまたはビューを作成しないでください。
system.profile ドキュメントの例
以下は、スタンドアロンでの操作用のsystem.profileコレクションにあるサンプル ドキュメントの一部を示しています。
system.profile内の次のドキュメントは、検索操作を反映しています。
{ "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, "queryHash" : "811451DD", "planCacheKey" : "759981BA", "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, "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" }
update（および delete）の操作のプロファイル エントリには、更新コマンド全体が含まれています。
次の例えでは、 reportという名前のコレクションに対するupdate操作を反映しています。
{ "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, "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" }
出力リファレンス
For any single operation, the documents created by the database profiler will include a subset of the following fields. これらのドキュメントで正確にどのフィールドが選ばれるかは、操作の種類によって異なります。
低速操作の場合、プロファイラー エントリと診断ログ メッセージにstorage情報が含まれます。
注意
MongoDB のバージョンに固有の出力については、適切なバージョンの MongoDB マニュアルを参照してください。
system.profile.op操作の種類。可能な値は次のとおりです。
commandcountdistinctgeoNeargetMoregroupinsertmapReducequeryremoveupdate
system.profile.commandこの操作に関連付けられた完全なコマンドオブジェクトを含むドキュメント。
たとえば、次の出力には、
testという名前のデータベース内のitemsという名前のコレクションに対するfind操作のコマンド オブジェクトが含まれています。"command" : { "find" : "items", "filter" : { "sku" : 1403978 }, ... "$db" : "test" } 次の出力例には、
testという名前のデータベース内のitemsという名前のコレクションで、カーソル ID19234103609を持つ コマンドによって生成されたgetMore操作のコマンド オブジェクトが含まれています。"command" : { "getMore" : NumberLong("19234103609"), "collection" : "items", "batchSize" : 10, ... "$db" : "test" }, コマンド ドキュメントが 50 キロバイトを超える場合、ドキュメントの形式は次のようになります。
"command" : { "$truncated": <string>, "comment": <string> } $truncatedフィールドには、ドキュメントのcommentフィールド（存在する場合）を除いたドキュメントの文字列のサマリーが含まれます。サマリーが依然として 50 キロバイトを超える場合は、さらに切り捨てられ、文字列の末尾に省略記号 (...) が表示されます。操作にコメントが渡された場合、
commentフィールドが存在します。任意のデータベースコマンドにコメントを添付できます。
system.profile.originatingCommandバージョン 3.6 で変更。
カーソルから次のバッチの結果を検索する
"getmore"操作の場合、originatingCommandフィールドには最初にそのカーソルを作成したコマンド オブジェクト全体が含まれます（例:findまたはaggregate）。
system.profile.keysExaminedバージョン 3.2.0 で変更。
system.profile.nscannedから名前が変更されました。 操作を実行するために MongoDB がスキャンしたインデックスキーの数。一般に、
keysExaminedがnreturnedより大幅に高い場合、データベースは結果ドキュメントを見つけるために多くのインデックス キーをスキャンしています。クエリのパフォーマンスを向上させるには、インデックスの作成や調整を検討してください。バージョン 3.4 で変更。
keysExaminedは、以下のコマンドと操作で使用できます。
system.profile.docsExaminedバージョン 3.2.0 での変更:
system.profile.nscannedObjectsから名前が変更されました。操作を実行するために MongoDB がスキャンしたコレクション内のドキュメント数。
バージョン 3.4 で変更。
docsExaminedは、以下のコマンドと操作で使用できます。
system.profile.hasSortStageバージョン 3.2.0 での変更:
system.profile.scanAndOrderから名前が変更されました。hasSortStageはブール値で、クエリがインデックス内の順序を使用して、要求されたソート結果を返すことができない場合にtrueになります。つまり、MongoDB は、カーソルからドキュメントを受け取った後、ドキュメントをソートする必要があります。このフィールドが表示されるのは、値がtrueのときだけです。バージョン 3.4 で変更。
hasSortStageは、以下のコマンドと操作で使用できます。getMore（OP_GET_MORE とcommand）
system.profile.usedDiskバージョン 4.2の新機能
メモリ制限が原因で、集計段階で一時ファイルにデータが書込み (write) されたかどうかを示すブール値。
usedDiskが true の場合にのみ表示されます。
system.profile.fromMultiPlannerバージョン3.2.5の新機能。
クエリ プランナーがクエリの最適な実行プランを選択する前に複数のプランを評価したかどうかを示すブール値。
値が
trueの場合にのみ存在します。
system.profile.replannedバージョン3.2.5の新機能。
クエリシステムがキャッシュされたプランをエビクションし、すべての候補プランを再評価したかどうかを示すブール値。
値が
trueの場合にのみ存在します。
system.profile.replanReasonキャッシュされたプランがエビクションされた具体的な理由を示す文字列。
replannedの値がtrueの場合にのみ存在します。
system.profile.keysDeleted3.4 で削除されました。
操作内でアップデートによって変更されたインデックスキーの数。 インデックス キーを変更すると、データベースは古いキーを削除し、新しいキーを B 木インデックスに挿入する必要があるため、わずかなパフォーマンス コストが発生します。
system.profile.writeConflicts書込み (write) 操作中に発生した競合の数。たとえば、
update操作が別のupdate操作と同じドキュメントを変更しようとした場合などです。書込み競合 (write conflict) も参照してください。
system.profile.numYield他の操作を完了させるために操作が中断した回数。通常、MongoDB がまだ完全にメモリに読み込んでいないデータにアクセスする必要がある場合、操作は中断します。これにより、MongoDB が中断された操作のデータを読み込んでいる間に、メモリにデータがある他の操作を完了できます。詳しくは、操作が中断されるタイミングに関する FAQ を参照してください。
system.profile.queryHashクエリシェイプのハッシュを表す 16進数の文字列で、クエリシェイプのみに依存します。
queryHashは、同じクエリシェイプでもスロー クエリ（書き込み (write) 操作のクエリフィルターを含む）を識別するのに役立ちます。注意
他のハッシュ関数と同様に、2 つの異なるクエリシェイプで同じハッシュ値が生成される場合があります。ただし、異なるクエリシェイプ間でハッシュ衝突が発生する可能性は低くなります。
queryHashとplanCacheKeyの詳細については、「queryHashとplanCacheKey」を参照してください。バージョン 4.2の新機能
system.profile.planCacheKeyクエリに関連付けられたプラン キャッシュ エントリのキーのハッシュです。
queryHashと違ってplanCacheKeyは、クエリシェイプとそのシェイプで現在使用可能なインデックスの両方の関数です。具体的には、クエリシェイプをサポート可能なインデックスが追加または削除された場合、planCacheKey値は変化しますが、queryHashの値は変化しません。queryHashとplanCacheKeyの詳細については、「queryHashとplanCacheKey」を参照してください。バージョン 4.2の新機能
system.profile.lockssystem.profile.locksは、操作中に保持されるさまざまなロック タイプとロック モードに関する情報を提供します。使用可能なロック タイプは、以下のとおりです。
ロック タイプ説明ParallelBatchWriterMode並列バッチ書込みモードのロックを表します。
以前のバージョンでは、PBWM 情報は
Globalロック情報の一部として報告されていました。ReplicationStateTransitionレプリカセットの状態遷移に対して取得されたロックを表します。
Globalグローバル ロックを表します。
Databaseデータベース ロックを表します。
Collectionコレクション ロックを表します。
Mutexミューテックスを表します。
Metadataメタデータ ロックを表します。
oplogoplog のロックを表します。
ロック タイプで使用可能なロック モードは次のとおりです。
ロックモード説明R共有ロック（S）を表します。
W排他ロック（X）を表します。
rインテント共有ロック（IS）を表します。
wインテント排他ロック（IX）を表します。
さまざまなロック タイプに対して返されるロック情報には、次のものが含まれます。
system.profile.locks.acquireWaitCountロックが競合モードで保持されていたために操作が
acquireCountロックの取得を待機しなければならなかった回数。acquireWaitCountはacquireCountより小さいです。
system.profile.locks.timeAcquiringMicros操作がロックを取得するために待機しなければならなかった累計時間（マイクロ秒単位）。
timeAcquiringMicrosをacquireWaitCountで割ると、特定のロック モードのおおよその平均待機時間が得られます。
ロック モードの詳細については、「MongoDB ではどのようなタイプのロックを使用しますか」を参照してください。
system.profile.authorizationバージョン 5.0.0 の新機能。
各操作でユーザー キャッシュがアクセスされる回数。これらのメトリクスは、操作がユーザー キャッシュに少なくとも 1 回アクセスした場合にのみ表示されます。
これらのメトリクスは、低速操作ロギングまたはデータベース プロファイリングが有効になっている場合にのみ使用できます。
system.profile.authorizationはdb.currentOp()の出力に含まれていません。
system.profile.storageバージョン 4.2 の新機能（ 4.0.9 以降でも利用可能）
system.profile.storageの情報は、storage engine データと操作の待機時間に関するメトリクスを提供します。特定のストレージ メトリクスは、値が 0 より大きい場合にのみ返されます。
system.profile.storage.data.bytesReadバージョン 4.2 の新機能（ 4.0.9 以降でも利用可能）
操作によってディスクからキャッシュに読み取られたバイト数。
ディスクからキャッシュに読み込まれるデータには、クエリの実行に必要なものがすべて含まれています。データがすでにキャッシュにある場合、ディスクから読み込まれるバイト数は
0になる可能性があります。ディスクから読み取られるバイト数には、クエリされたドキュメント以上のものが含まれます。
WiredTiger はページ単位で読み取り、ページには 1 つまたは複数のドキュメントが含まれる場合があります。ドキュメントがページ内にある場合、そのページのすべてのドキュメントがキャッシュに読み込まれ、
bytesReadの値に含められます。キャッシュにページ管理（エビクションや再読み込みなど）が必要な場合、
bytesReadの値にはこれらの操作でディスクから読み取られたデータが含まれます。インデックスがキャッシュにない場合、またはキャッシュ内のインデックスが古い場合、WiredTigerはディスクからいくつかの内部ページとリーフ ページを読み取って、キャッシュ内のインデックスを再構築します。
system.profile.storage.data.timeReadingMicrosバージョン 4.2 の新機能（ 4.0.9 以降でも利用可能）
操作がディスクからの読み取りに要した時間（マイクロ秒単位）。
system.profile.storage.data.bytesWrittenバージョン 4.2 の新機能（ 4.0.9 以降でも利用可能）
操作によってキャッシュからディスクに書込まれたバイト数。
WiredTiger では通常、ディスクに書き込むクエリは必要ありません。クエリによって変更されたデータは、メモリ内キャッシュに書き込まれ、WiredTiger はエビクションまたはチェックポイント操作の一部としてディスクにフラッシュします。このような場合、
bytesWrittenは 0 と表示されます。クエリを実行中のスレッドが強制的なページ管理（エビクションなど）を必要とする場合、WiredTiger はページの内容をディスクに書込みます。このフラッシュには、クエリ自体による変更とは無関係なデータが含まれる可能性が高く、
bytesWrittenが予想よりも高い値を示すことがあります。
system.profile.storage.data.timeWritingMicrosバージョン 4.2 の新機能（ 4.0.9 以降でも利用可能）
操作がディスクへの書込み (write) に要した時間（マイクロ秒単位）。
system.profile.storage.timeWaitingMicros.cacheバージョン 4.2 の新機能（ 4.0.9 以降でも利用可能）
操作がキャッシュ内のスペースを待機しなければならなかった時間（マイクロ秒単位）。
system.profile.responseLength操作の結果ドキュメントの長さ（バイト単位）。
responseLengthが大きいとパフォーマンスに影響する可能性があります。クエリ操作の結果ドキュメントのサイズを制限するには、次のいずれかを使用できます。注意
MongoDB がクエリ プロファイル情報をログに書込むとき、
responseLengthの値はreslenという名前のフィールドにあります。
system.profile.protocolMongoDB ワイヤプロトコルのリクエスト メッセージ形式。
system.profile.millismongodの観点から見た、操作の開始から終了までの時間（ミリ秒単位）。
system.profile.execStatsクエリ操作の実行統計を含むドキュメント。その他の操作の場合、値は空のドキュメントです。
system.profile.execStatsにより統計情報はツリー形式で表示されます。クエリ操作の各段階で実行された操作に関する統計情報が、各ノードから収集されます。注意
execStatsの次のフィールド リストは、返されるフィールドがステージごとに異なるため、網羅的なものではありません。
system.profile.appNameバージョン 3.4 で追加。
操作を実行したクライアント・アプリケーションの識別子。
appName接続stringオプションを使用して、appNameフィールドにカスタム値を設定します。
system.profile.allUsersセッションの認証済みユーザー情報（ユーザー名とデータベース）の配列。 「自己管理型配置のユーザー 」も参照してください。