{
   "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

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

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: バージョン 3.6 で変更。
カーソルから次のバッチの結果を検索する "getmore" 操作の場合、originatingCommand フィールドには最初にそのカーソルを作成したコマンドオブジェクト全体が含まれます（例: find またはaggregate）。

system.profile.cursorid: query と getmore 操作によってアクセスされるカーソルの ID。

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 は、以下のコマンドと操作で使用できます。

system.profile.usedDisk

バージョン 4.2の新機能

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

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

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

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

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

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

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

system.profile.fromMultiPlanner

バージョン3.2.5の新機能。

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

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

system.profile.replanned

バージョン3.2.5の新機能。

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

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

system.profile.replanReason

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

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

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

system.profile.keysDeleted

3.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.locks

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

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

ロックタイプ	説明
`ParallelBatchWriterMode`	並列バッチ書込みモードのロックを表します。以前のバージョンでは、PBWM 情報は `Global` ロック情報の一部として報告されていました。
`ReplicationStateTransition`	レプリカセットの状態遷移に対して取得されたロックを表します。
`Global`	グローバルロックを表します。
`Database`	データベースロックを表します。
`Collection`	コレクションロックを表します。
`Mutex`	ミューテックスを表します。
`Metadata`	メタデータロックを表します。
`oplog`	oplog のロックを表します。

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

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

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

system.profile.locks.acquireCount: 操作が指定モードでロックを取得した回数。

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

system.profile.locks.timeAcquiringMicros

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

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

system.profile.locks.deadlockCount: ロック取得を待機中に操作でデッドロックが発生した回数。

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

system.profile.authorization

バージョン 5.0.0 の新機能。

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

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

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

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

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

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

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.storage.timeWaitingMicros.schemaLock: バージョン 4.2 の新機能（ 4.0.9 以降でも利用可能）
操作 (スキーマを変更した場合) がスキーマロックを取得するまで待機しなければならなかった時間（マイクロ秒単位）。

system.profile.storage.timeWaitingMicros.handleLock: バージョン 4.2 の新機能（ 4.0.9 以降でも利用可能）
操作が必要なデータハンドルのロックを取得するために待機しなければならなかった時間（マイクロ秒単位）。

system.profile.nreturned: 操作によって返されたドキュメントの数。

system.profile.responseLength

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

注意

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

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

system.profile.millis: mongodの観点から見た、操作の開始から終了までの時間（ミリ秒単位）。

system.profile.planSummary: バージョン 3.4 で追加。
実行プランの概要。

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: バージョン 3.4 で追加。
操作を実行したクライアント・アプリケーションの識別子。 appName接続stringオプションを使用して、appName フィールドにカスタム値を設定します。

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

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

戻る

Database Profiler

パフォーマンスの最適化

注意

警告

system.profile ドキュメントの例

出力リファレンス

注意

注意

注意

注意

`system.profile` ドキュメントの例