Docs Menu
Docs Home
/ /
Database Profiler

Salida del perfilador de base de datos

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 perfilará 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 informan la misma información de diagnóstico básica para todas las operaciones CRUD, incluidas las siguientes:

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.

Ya no es posible realizar ninguna operación, incluidas las lecturas, en la colección system.profile desde dentro de una transacción.

A continuación se presentan algunos documentos de muestra encontrados en la colección system.profile para operaciones en un autónomo:

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,
"queryHash" : "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,
"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 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,
"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"
}

Para cualquier operación, los documentos creados por el generador de perfiles de base de datos incluirán un subconjunto de los siguientes campos. La selección precisa de campos en estos documentos depende del tipo de operación.

Para operaciones lentas, las entradas del generador de perfiles y los mensajes del registro de diagnóstico incluyen storage informació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.op

El tipo de operación. Los valores posibles son:

  • command

  • count

  • distinct

  • geoNear

  • getMore

  • group

  • insert

  • mapReduce

  • query

  • remove

  • update

system.profile.ns

El 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.command

Un 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 find llamada items en una base de datos test llamada:

"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 getMore cursor 19234103609 en una colección llamada items en una base de datos test llamada:

"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 $truncated contiene un resumen de cadena del documento, excluyendo el campo comment, 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 comment campo 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.originatingCommand

Cambiado en la versión 3.6.

Para las operaciones "getmore" que recuperan el siguiente lote de resultados de un cursor, el campo originatingCommand contiene el objeto de comando completo (por ejemplo, find o aggregate) que creó originalmente ese cursor.

system.profile.cursorid

El ID del cursor al que se accede mediante operaciones query y getmore.

system.profile.keysExamined

Cambiado en la versión 3.2.0.

Renombrado system.profile.nscanned de. Número de claves de índice que MongoDB analizó para realizar la operación.

En general, si es keysExamined nreturned 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 las consultas.

Cambiado en la versión 3.4.

keysExamined está disponible para los siguientes comandos y operaciones:

system.profile.docsExamined

Cambiado en la 3.2.0 versión: Renombrado system.profile.nscannedObjects de.

La cantidad de documentos de la colección que MongoDB escaneó para realizar la operación.

Cambiado en la versión 3.4.

docsExamined está disponible para los siguientes comandos y operaciones:

system.profile.hasSortStage

Cambiado en la 3.2.0 versión: Renombrado system.profile.scanAndOrder de.

hasSortStage es un valor booleano que se true convierte 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 valor true es.

Cambiado en la versión 3.4.

hasSortStage está disponible para los siguientes comandos y operaciones:

system.profile.usedDisk

Nuevo en la versión 4.2.

Un valor booleano que indica si alguna etapa de agregación escribió datos en archivos temporales debido a restricciones de memoria.

Solo aparece si usedDisk es verdadero.

system.profile.ndeleted

El número de documentos eliminados por la operación.

system.profile.ninserted

El número de documentos insertados por la operación.

system.profile.nMatched

El número de documentos que coinciden con la condición de consulta para la operación de actualización.

system.profile.nModified

El número de documentos modificados por la operación de actualización.

system.profile.upsert

Un valor booleano que indica el valor de la opción upsert de la operación de actualización. Solo aparece si upsert es verdadero.

system.profile.fromMultiPlanner

Un 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.replanned

Un 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.replanReason

Una 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 replanned es true.

system.profile.keysInserted

El número de claves de índice insertadas para una operación de escritura determinada.

system.profile.keysDeleted

Eliminado en 3.4.

El número de claves de índice que la actualización modificó durante la operación. Cambiar una clave de índice implica un pequeño coste de rendimiento, ya que la base de datos debe eliminar la clave anterior e insertar una nueva en el índice del árbol B.

system.profile.writeConflicts

El número de conflictos encontrados durante la operación de guardar; por ejemplo, una operación de update intenta modificar el mismo documento que otra operación de update. Consulte también el conflicto de escritura.

system.profile.numYield

El 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.queryHash

Una cadena hexadecimal que representa un hash de la forma de la consulta y depende únicamente de la forma de la consulta. queryHash puede ayudar a identificar consultas lentas (incluido el filtro de consulta de operaciones de escritura) con la misma forma de consulta.

Nota

Como con cualquier función encriptada, dos formas del query diferentes pueden dar como resultado el mismo valor encriptado. Sin embargo, es poco probable que ocurran colisiones encriptadas entre diferentes formas del query.

Para obtener más información sobre queryHash y,planCacheKey consulte queryHash y.planCacheKey

Nuevo en la versión 4.2.

system.profile.planCacheKey

Un hash de la clave para la entrada de caché del plan asociada con el query.

A diferencia queryHash de, depende tanto de la forma de la consulta como de los índices disponibles para ella. Es decir, si se añaden o eliminan índices compatibles con la forma de la consulta,planCacheKey el planCacheKey valor de podría cambiar, mientras que el queryHash de no cambiaría.

Para obtener más información sobre queryHash y,planCacheKey consulte queryHash y.planCacheKey

Nuevo en la versión 4.2.

system.profile.queryFramework

El marco de consulta utilizado para procesar una operación.

system.profile.locks

El proporciona system.profile.locks información sobre varios tipos de bloqueo y modos de bloqueo mantenidos durante la operación.

Los posibles tipos de bloqueo son:

Tipo de bloqueo
Descripción

ParallelBatchWriterMode

Representa 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.

ReplicationStateTransition

Representa el bloqueo tomado para las transiciones de estado del nodo del set de réplicas.

Global

Representa el bloqueo global.

Database

Representa el bloqueo de la base de datos.

Collection

Representa un bloqueo de colección.

Mutex

Representa una exclusión mutua.

Metadata

Representa un bloqueo de metadatos.

oplog

Representa un bloqueo en el oplog.

Los posibles modos de bloqueo para los tipos de cerradura son los siguientes:

Modo de bloqueo
Descripción

R

Representa un bloqueo compartido (S).

W

Representa un bloqueo exclusivo (X).

r

Representa un bloqueo de intención compartida (IS).

w

Representa un bloqueo de intención exclusiva (IX).

La información de bloqueo devuelta para los distintos tipos de bloqueo incluye:

system.profile.locks.acquireCount

Número de veces que la operación adquirió el bloqueo en el modo especificado.

system.profile.locks.acquireWaitCount

Número de veces que la operación tuvo que esperar las acquireCount adquisiciones de bloqueo porque los bloqueos se mantuvieron en un modo conflictivo. es menor oacquireWaitCount igual acquireCount a.

system.profile.locks.timeAcquiringMicros

Tiempo acumulado en microsegundos que la operación tuvo que esperar para adquirir los bloqueos.

timeAcquiringMicros dividido por acquireWaitCount proporciona un tiempo de espera promedio aproximado para la moda de bloqueo particular.

system.profile.locks.deadlockCount

Nú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.authorization

Novedades 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.authorization no está incluido en la db.currentOp() salida.

system.profile.authorization.startedUserCacheAcquisitionAttempts

La cantidad de veces que la operación intentó acceder a la caché del usuario.

system.profile.authorization.completedUserCacheAcquisitionAttempts

El número de veces que la operación recuperó datos de usuario de la caché de usuario.

system.profile.authorization.userCacheWaitTimeMicros

El tiempo total que la operación pasó esperando respuestas de la caché del usuario.

system.profile.storage

Novedades en la 4.2 versión: (Tambiéndisponible a partir 4.0.9 de)

La información proporciona métricas sobre los datos del motor de almacenamiento y el tiempo de espera para la system.profile.storage operación.

Las métricas de almacenamiento específicas se devuelven solo si los valores son mayores que cero.

system.profile.storage.data.bytesRead

Novedades en la 4.2 versión: (Tambiéndisponible a partir 4.0.9 de)

Nú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 bytesRead incluye 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.timeReadingMicros

Novedades en la 4.2 versión: (Tambiéndisponible a partir 4.0.9 de)

Tiempo en microsegundos que la operación tuvo que emplear para leer desde el disco.

system.profile.storage.data.bytesWritten

Novedades en la 4.2 versión: (Tambiéndisponible a partir 4.0.9 de)

Nú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, bytesWritten se 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 bytesWritten muestre un valor superior al esperado.

system.profile.storage.data.timeWritingMicros

Novedades en la 4.2 versión: (Tambiéndisponible a partir 4.0.9 de)

Tiempo en microsegundos que la operación tuvo que tardar en escribir en el disco.

system.profile.storage.timeWaitingMicros.cache

Novedades en la 4.2 versión: (Tambiéndisponible a partir 4.0.9 de)

Tiempo en microsegundos que la operación tuvo que esperar espacio en la caché.

system.profile.storage.timeWaitingMicros.schemaLock

Novedades en la 4.2 versión: (Tambiéndisponible a partir 4.0.9 de)

Tiempo en microsegundos que la operación (si modificaba el esquema) tuvo que esperar para adquirir un bloqueo de esquema.

system.profile.storage.timeWaitingMicros.handleLock

Novedades en la 4.2 versión: (Tambiéndisponible a partir 4.0.9 de)

Tiempo en microsegundos que la operación tuvo que esperar para adquirir el bloqueo en los manejadores de datos necesarios.

system.profile.nreturned

El número de documentos devueltos por la operación.

system.profile.responseLength

La 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 responseLength opciones:

Nota

Cuando MongoDB escribe información del perfil de consulta en el registro, el valor está en un responseLength campo reslen llamado.

system.profile.protocol

El formato del mensaje de solicitud del protocolo MongoDB Wire.

system.profile.millis

El tiempo en milisegundos desde la perspectiva de desde el inicio de la operación hasta el final de la mongod operación.

system.profile.planSummary

Un resumen del plan de ejecución.

system.profile.execStats

Un documento que contiene las estadísticas de ejecución de la consulta. Para otras operaciones, el valor es un documento vacío.

system.profile.execStats presenta 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 execStats no pretende ser exhaustiva ya que los campos devueltos varían según la etapa.

system.profile.execStats.stage

El nombre descriptivo de la operación realizada como parte de la ejecución de la consulta; por ejemplo

  • COLLSCAN para un escaneo de colección

  • IXSCAN para el escaneo de claves de índice

  • FETCH para la recuperación de documentos

system.profile.execStats.inputStages

Una matriz que contiene estadísticas para las operaciones que son las etapas de entrada de la etapa actual.

system.profile.ts

La marca de tiempo de la operación.

system.profile.client

La dirección IP o el nombre del host de la conexión cliente desde donde se origina la operación.

system.profile.appName

El identificador de la aplicación cliente que ejecutó la operación. Utilice la appName opción de cadena de conexión para establecer un valor personalizado para el appName campo.

system.profile.allUsers

Una 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.

system.profile.user

El usuario autenticado que ejecutó la operación. Si la operación no fue ejecutada por un usuario autenticado, el valor de este campo es una string vacía.

Volver

Database Profiler

En esta página