El generador de perfiles de base de datos captura información sobre operaciones de lectura y escritura, operaciones del cursor y comandos de la base de datos. Para configurar el perfil de base de datos y establecer los umbrales para la captura de datos del perfil, consulte Sección deperfilador de base de datos.
El generador de perfiles de base de datos escribe datos en el system.profileColección, que es una colección limitada. Para ver la salida del generador de perfiles, utilice consultas MongoDB normales en la system.profile colección.
Nota
Debido a que el generador de perfiles de base de datos escribe datos system.profile en la colección de una base de datos, el generador de perfiles registra cierta actividad de escritura, incluso para bases de datos que, de otro modo, serían de solo lectura.
currentOp y el generador de perfiles de base de datos informa la misma información de diagnóstico básica para las operaciones CRUD, incluida lo siguiente:
getMore(OP_GET_MORE ycommand)
Estas operaciones también se incluyen en el registro de las query lentas. Consulta slowOpThresholdMs para obtener más información sobre el registro de query lentas.
Al usar el cifrado consultable, las operaciones CRUD contra colecciones cifradas se omiten en la colección. Para más información, system.profile consulte Redacción.
Ya no es posible realizar ninguna operación, incluidas las lecturas, en la colección system.profile desde dentro de una transacción.
Campos de salida
Para cada operación, los documentos creados por el generador de perfiles de base de datos incluyen un subconjunto de los siguientes campos. La selección precisa de campos en estos documentos depende del tipo de operación.
Nota
Para obtener la salida específica de la versión de su MongoDB, consulte la versión apropiada del Manual de MongoDB.
system.profile.opEl tipo de operación. Los valores posibles son:
commandcountdistinctgeoNeargetMoregroupinsertmapReducequeryremoveupdate
system.profile.nsEl espacio de nombres al que se dirige la operación. En MongoDB, los espacios de nombres tienen la forma de la base de datos, seguido de un punto
.() y, a continuación, del nombre de la colección.
system.profile.commandUn documento que contiene el objeto de comando completo asociado con esta operación.
Por ejemplo, la siguiente salida contiene el objeto de comando para una operación en una colección
findllamadaitemsen una base de datostestllamada:"command" : { "find" : "items", "filter" : { "sku" : 1403978 }, ... "$db" : "test" } El siguiente ejemplo de salida contiene el objeto de comando para una operación generada por un comando con ID de
getMorecursor19234103609en una colección llamadaitemsen una base de datostestllamada:"command" : { "getMore" : Long("19234103609"), "collection" : "items", "batchSize" : 10, ... "$db" : "test" }, Si el documento de comando supera los 50 kilobytes, el documento tiene el siguiente formato:
"command" : { "$truncated": <string>, "comment": <string> } El campo
$truncatedcontiene un resumen de cadena del documento, excluyendo el campocomment, si está presente. Si el resumen aún supera los 50 kilobytes, se trunca aún más, lo que se indica con puntos suspensivos (...) al final de la cadena.El
commentcampo está presente si se pasó un comentario a la operación. Se puede adjuntar un comentario a cualquier comando de base de datos.
system.profile.originatingCommandPara las operaciones
"getmore"que recuperan el siguiente lote de resultados de un cursor, el campooriginatingCommandcontiene el objeto de comando completo (por ejemplo,findoaggregate) que creó originalmente ese cursor.
system.profile.keysExaminedLa cantidad de claves de índice que MongoDB escaneó para realizar la operación.
En general, si
keysExaminedes mucho mayor que; la base de datos está escaneando varias claves de índice para encontrar los documentos resultantes. Considere crear o ajustar índices para mejorar el rendimiento de lasnreturnedconsultas.keysExaminedestá disponible para los siguientes comandos y operaciones:
system.profile.docsExaminedLa cantidad de documentos de la colección que MongoDB escaneó para realizar la operación.
docsExaminedestá disponible para los siguientes comandos y operaciones:
system.profile.hasSortStagehasSortStagees un valor booleano que setrueconvierte en cuando una consulta no puede usar el orden del índice para devolver los resultados ordenados solicitados; es decir, MongoDB debe ordenar los documentos después de recibirlos de un cursor. El campo solo aparece cuando el valortruees.hasSortStageestá disponible para los siguientes comandos y operaciones:getMore(OP_GET_MORE ycommand)
system.profile.usedDiskUn valor booleano que indica si alguna etapa de agregación escribió datos en archivos temporales debido a restricciones de memoria.
Solo aparece si
usedDiskes verdadero.
system.profile.nMatchedEl número de documentos que coinciden con la condición de consulta para la operación de actualización.
system.profile.upsertUn valor booleano que indica el valor de la opción
upsertde la operación de actualización. Solo aparece siupsertes verdadero.
system.profile.fromMultiPlannerUn valor booleano que indica si el planificador de consultas evaluó varios planes antes de elegir el plan de ejecución ganador para la consulta.
Solo se presenta cuando el valor es
true.
system.profile.replannedUn booleano que indica si el sistema de query eliminó un plan en caché y re-evaluó todos los planes candidatos.
Solo se presenta cuando el valor es
true.
system.profile.replanReasonUna cadena que indica el motivo específico por el que se desalojó un plan almacenado en caché.
Sólo está presente cuando el valor de
replannedestrue.
system.profile.keysInsertedEl número de claves de índice insertadas para una operación de escritura determinada.
system.profile.writeConflictsEl número de conflictos encontrados durante la operación de guardar; por ejemplo, una operación de
updateintenta modificar el mismo documento que otra operación deupdate. Consulte también el conflicto de escritura.
system.profile.numYieldEl número de veces que la operación cedió para permitir que otras operaciones se completaran. Normalmente, las operaciones ceden cuando necesitan acceder a datos que MongoDB aún no ha leído completamente en memoria. Esto permite que otras operaciones con datos en memoria se completen mientras MongoDB lee los datos para la operación que cede. Para más información, consulte las preguntas frecuentes sobre cuándo ceden las operaciones.
system.profile.queryHashA partir de MongoDB 8.0, el campo
queryHashexistente se duplica en un nuevo campo llamadoplanCacheShapeHash. Si estás utilizando una versión anterior de MongoDB, solo verás el campoqueryHash. Las versiones futuras de MongoDB removerán el campoqueryHashobsoleto y deberás utilizar el campoplanCacheShapeHashen su lugar.
system.profile.queryShapeHashNuevo en la versión 8.0.
queryShapeHashEs una cadena hexadecimal con el hash de una forma de consulta. Para más detalles, consulte Formas de consulta.
system.profile.planCacheShapeHashUna cadena hexadecimal que representa un hash de la forma de consulta de caché de plan y depende únicamente de la forma de consulta de caché de plan.
planCacheShapeHashpuede ayudar a identificar consultas lentas, incluido el filtro de consulta de operaciones de escritura, con la misma forma de consulta de caché de plan.Nota
Como con cualquier función hash, dos formas diferentes de formas del query en caché del plan pueden dar lugar al mismo valor hash. Sin embargo, es poco probable que ocurran colisiones de hash entre diferentes formas del query de la caché del plan.
Para obtener más información sobre
planCacheShapeHashy,planCacheKeyconsulte planCacheShapeHash y planCacheKey.A partir de MongoDB 8.0, el campo
queryHashexistente se duplica en un nuevo campo llamadoplanCacheShapeHash. Si estás utilizando una versión anterior de MongoDB, solo verás el campoqueryHash. Las versiones futuras de MongoDB removerán el campoqueryHashobsoleto y deberás utilizar el campoplanCacheShapeHashen su lugar.
system.profile.planCacheKeyUn hash de la clave para la entrada de caché del plan asociada con el query.
A diferencia
planCacheShapeHashde,planCacheKeydepende tanto de la forma de consulta de la caché del plan como de los índices disponibles para dicha forma. En concreto, si se añaden o eliminan índices compatibles con la forma de consulta, elplanCacheKeyvalor de puede cambiar, pero el deplanCacheShapeHashno.Para obtener más información sobre
planCacheShapeHashy,planCacheKeyconsulte planCacheShapeHash y planCacheKey.A partir de MongoDB 8.0, el campo
queryHashexistente se duplica en un nuevo campo llamadoplanCacheShapeHash. Si estás utilizando una versión anterior de MongoDB, solo verás el campoqueryHash. Las versiones futuras de MongoDB removerán el campoqueryHashobsoleto y deberás utilizar el campoplanCacheShapeHashen su lugar.
system.profile.queryFrameworkEl marco de consulta utilizado para procesar una operación.
system.profile.locksEl proporciona
system.profile.locksinformación sobre varios tipos de bloqueo y modos de bloqueo mantenidos durante la operación.Los posibles tipos de bloqueo son:
Tipo de bloqueoDescripciónParallelBatchWriterModeRepresenta un bloqueo para el modo de escritura por lotes paralelo.
En versiones anteriores, la información de PBWM se informaba como parte de la información de bloqueo de
Global.ReplicationStateTransitionRepresenta el bloqueo tomado para las transiciones de estado del nodo del set de réplicas.
GlobalRepresenta el bloqueo global.
DatabaseRepresenta el bloqueo de la base de datos.
CollectionRepresenta un bloqueo de colección.
MutexRepresenta una exclusión mutua.
MetadataRepresenta un bloqueo de metadatos.
DDLDatabaseRepresenta un bloqueo de base de datos DDL.
Nuevo en la versión 7.1.
DDLCollectionRepresenta un bloqueo de colección DDL.
Nuevo en la versión 7.1.
oplogRepresenta un bloqueo en el oplog.
Los posibles modos de bloqueo para los tipos de cerradura son los siguientes:
Modo de bloqueoDescripciónRRepresenta un bloqueo compartido (S).
WRepresenta un bloqueo exclusivo (X).
rRepresenta un bloqueo de intención compartida (IS).
wRepresenta un bloqueo de intención exclusiva (IX).
La información de bloqueo devuelta para los distintos tipos de bloqueo incluye:
system.profile.locks.acquireCountNúmero de veces que la operación adquirió el bloqueo en el modo especificado.
system.profile.locks.acquireWaitCountNúmero de veces que la operación tuvo que esperar las
acquireCountadquisiciones de bloqueo porque los bloqueos se mantuvieron en un modo conflictivo. es menor oacquireWaitCountigualacquireCounta.
system.profile.locks.timeAcquiringMicrosTiempo acumulado en microsegundos que la operación tuvo que esperar para adquirir los bloqueos.
timeAcquiringMicrosdividido poracquireWaitCountproporciona un tiempo de espera promedio aproximado para la moda de bloqueo particular.
system.profile.locks.deadlockCountNúmero de veces que la operación encontró bloqueos mientras esperaba adquisiciones de bloqueo.
Para obtener más información sobre los modos de bloqueo, consulte ¿Qué tipo de bloqueo utiliza MongoDB?.
system.profile.authorizationNovedades en la versión 5.0.0.
Número de veces que se accede a la caché del usuario en cada operación. Estas métricas solo se muestran cuando una operación ha accedido a la caché del usuario al menos una vez.
Estas métricas solo están disponibles cuando está habilitado el registro de operaciones lentas o la creación de perfiles de base de datos.
system.profile.authorizationno está incluido en ladb.currentOp()salida.system.profile.authorization.startedUserCacheAcquisitionAttemptsLa cantidad de veces que la operación intentó acceder a la caché del usuario.
system.profile.storageLa información proporciona métricas sobre los datos del motor de almacenamiento y el tiempo de espera para la
system.profile.storageoperación.Las métricas de almacenamiento específicas se devuelven solo si los valores son mayores que cero.
system.profile.storage.data.bytesReadNúmero de bytes leídos por la operación desde el disco a la caché.
Los datos leídos del disco a la caché incluyen todo lo necesario para ejecutar la consulta. Si los datos ya están en la caché, el número de bytes leídos del disco podría ser
0.La cantidad de bytes leídos del disco incluye más que los documentos consultados:
WiredTiger lee en unidades de páginas, y cada página puede contener uno o varios documentos. Si un documento está en una página, todos los documentos de esa página se leen en la caché y se incluyen en el valor
bytesRead.Si la caché requiere administración de páginas (como desalojo o relecturas), el valor
bytesReadincluye los datos leídos desde el disco en estas operaciones.Si el índice no está en la memoria caché o el índice en la memoria caché está desactualizado, WiredTiger lee varias páginas internas y hojas del disco para reconstruir el índice en la memoria caché.
system.profile.storage.data.timeReadingMicrosTiempo en microsegundos que la operación tuvo que emplear para leer desde el disco.
system.profile.storage.data.bytesWrittenNúmero de bytes escritos por la operación desde la caché al disco.
WiredTiger normalmente no requiere que la consulta escriba en el disco. Los datos modificados por la consulta se escriben en una caché en memoria que WiredTiger vacía en el disco como parte de una operación de desalojo o punto de control. En tales casos,
bytesWrittense muestra como 0.Si el hilo que ejecuta la consulta requiere una gestión forzada de páginas (como una expulsión), WiredTiger escribe el contenido de la página en el disco. Es probable que este vaciado incluya datos no relacionados con los cambios realizados por la propia consulta, lo que puede provocar que
bytesWrittenmuestre un valor superior al esperado.
system.profile.storage.data.timeWritingMicrosTiempo en microsegundos que la operación tuvo que tardar en escribir en el disco.
system.profile.storage.timeWaitingMicros.cacheTiempo en microsegundos que la operación tuvo que esperar espacio en la caché.
system.profile.responseLengthLa longitud en bytes del documento de resultados de la operación. Un valor grande puede afectar el rendimiento. Para limitar el tamaño del documento de resultados de una consulta, puede usar cualquiera de las siguientes
responseLengthopciones:Nota
Cuando MongoDB escribe información del perfil de consulta en el registro, el valor está en un
responseLengthcamporeslenllamado.
system.profile.cpuNanosNuevo en la versión 6.3.
El tiempo total de CPU utilizado por una operación de query, en nanosegundos. Este campo solo está disponible en sistemas Linux.
system.profile.protocolEl formato del mensaje de solicitud del protocolo MongoDB Wire.
system.profile.millisEl tiempo en milisegundos desde la perspectiva de desde el inicio de la operación hasta el final de la
mongodoperación.
planningTimeMicrosNuevo en la versión 6.2.
El tiempo, en microsegundos, que el
findcomando oaggregatededicó a la planificación de la consulta.
system.profile.execStatsUn documento que contiene las estadísticas de ejecución de la consulta. Para otras operaciones, el valor es un documento vacío.
system.profile.execStatspresenta las estadísticas como un árbol; cada nodo proporciona las estadísticas de la operación ejecutada durante esa etapa de la operación de consulta.Nota
La siguiente lista de campos para
execStatsno pretende ser exhaustiva ya que los campos devueltos varían según la etapa.
system.profile.clientLa dirección IP o el nombre del host de la conexión cliente desde donde se origina la operación.
system.profile.appNameEl identificador de la aplicación cliente que ejecutó la operación. Utilice la
appNameopción de cadena de conexión para establecer un valor personalizado para elappNamecampo.
system.profile.allUsersUna matriz de información de usuario autenticado (nombre de usuario y base de datos) para la sesión. Consulte también Usuarios en implementaciones autogestionadas.
Ejemplo system.profile Documento
Los siguientes ejemplos presentan documentos de muestra encontrados en la colección para operaciones en un sistema system.profile independiente:
El siguiente documento de la colección muestra métricas para una operación de consulta system.profile de test.report muestra en la colección:
{ "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" : Long(3), "w" : Long(3) } }, "Database" : { "acquireCount" : { "r" : Long(3) }, "acquireWaitCount" : { "r" : Long(1) }, "timeAcquiringMicros" : { "r" : Long(69130694) } }, "Collection" : { "acquireCount" : { "r" : Long(3) } } }, "storage" : { "data" : { "bytesRead" : Long(14736), "timeReadingMicros" : Long(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" }
La colecciónsystem.profileincluye métricas para la operacióngetMore. En este ejemplo, getMore devuelve documentos adicionales de la colección test.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" : Long(3), "w" : Long(3) } }, "Database" : { "acquireCount" : { "r" : Long(3) }, "acquireWaitCount" : { "r" : Long(1) }, "timeAcquiringMicros" : { "r" : Long(69130694) } }, "Collection" : { "acquireCount" : { "r" : Long(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" }
A partir de MongoDB 8.0, el campo queryHash existente se duplica en un nuevo campo llamado planCacheShapeHash. Si estás utilizando una versión anterior de MongoDB, solo verás el campo queryHash. Las versiones futuras de MongoDB removerán el campo queryHash obsoleto y deberás utilizar el campo planCacheShapeHash en su lugar.
La entrada de perfil para la operación (y) contiene el comando de actualización update deletecompleto.
El siguiente documento de la colección muestra métricas para una operación de actualización de muestra en system.profile la test.report colección:
{ "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" : Long(6986), "w" : Long(13972) } }, "Database" : { "acquireCount" : { "w" : Long(6986) }, "acquireWaitCount" : { "w" : Long(1) }, "timeAcquiringMicros" : { "w" : Long(60899375) } }, "Collection" : { "acquireCount" : { "w" : Long(6986) } }, "Mutex" : { "acquireCount" : { "r" : Long(25000) } } }, "storage" : { "data" : { "bytesRead" : Long(126344060), "bytesWritten" : Long(281834762), "timeReadingMicros" : Long(94549), "timeWritingMicros" : Long(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" }