Saída do analisador de banco de dados

Nesta página

Documento de exemplo system.profile

Referência de saída

O analisador de banco de dados capta informações de dados sobre operações de leitura e gravação, operações do cursor e comandos do banco de dados. Para configurar o perfil do banco de dados e definir os limites para a captação de dados de perfil, consulte a seção Profiler de banco de dados.

O analisador de banco de dados grava dados na coleção system.profile, que é uma coleção com limite. Para visualizar o resultado do perfil, use queries MongoDB normais na coleção system.profile.

Observação

Como a implantação de reconhecimento de data center grava dados na collection system.profile em um reconhecimento de data center, a implantação criará o perfil de alguma atividade de gravação, mesmo para reconhecimento de data center que, de outra forma, são somente leitura.

currentOp e a implantação de reconhecimento de data center relatam as mesmas informações de diagnóstico básicas para todas as operações CRUD, incluindo o seguinte:

Essas operações também são incluídas no logging de queries lentas. Consulte slowOpThresholdMs para obter mais informações sobre registro de queries lentas.

Não é mais possível executar qualquer operação, inclusive leituras, na coleção system.profile em uma transação.

Aviso

Não tente criar uma coleção de séries temporais ou visualizar com o nome system.profile porque o servidor MongoDB falhará.

Documento de `system.profile` exemplo

A seguir, apresentamos alguns documentos de exemplo encontrados na collection system.profile para operações em um standalone:

O seguinte documento no system.profile reflete uma operação de localização:

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

A entrada de perfil para a operação update (e delete) contém o comando de atualização completo.

O exemplo a seguir reflete uma operação update em uma collection chamada 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,
   "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"
}

Referência de saída

Para qualquer operação individual, o documento criado pela implantação de banco de dados incluirá um subconjunto dos seguintes campo. A seleção precisa de campos nesses documentos depende do tipo de operação.

Para operações lentas, as entradas do analisador e as mensagens de registro de diagnóstico incluem informações storage .

Observação

Para a saída específica para a versão do seu MongoDB, consulte a versão apropriada do Manual MongoDB.

system.profile.op

O tipo de operação. Os valores possíveis são:

command
count
distinct
geoNear
getMore
group
insert
mapReduce
query
remove
update

system.profile.ns: O namespace que a operação visa. Os namespaces no MongoDB assumem a forma do database, seguido por um ponto (.), seguido pelo nome da coleção.

system.profile.command

Um documento contendo o objeto de comando completo associado a esta operação.

Por exemplo, a seguinte saída contém o objeto de comando para uma operação find em uma collection denominada items em um banco de dados denominado test:

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

O seguinte exemplo de saída contém o objeto de comando para uma operação getMore gerada por um comando com ID de cursor 19234103609 em uma collection denominada items em um banco de dados denominado test:

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

Se o documento de comando exceder 50 kilobytes, o documento terá o seguinte formulário:

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

O campo $truncated contém um resumo de strings do documento, excluindo o campo comment do documento, se presente. Se, mesmo assim, o resumo exceder 50 kilobytes, ele será ainda mais truncado, indicado por uma reticência (...) no final da string.

O campo comment está presente se algum comentário foi passado para a operação. Um comentário pode ser anexado a qualquer comando de banco de dados.

system.profile.originatingCommand: Alterado na versão 3.6.
Para operações do "getmore" que recuperam o próximo lote de resultados de um cursor, o campo originatingCommand contém o objeto de comando completo (por exemplo, find ou aggregate) que originalmente criou esse cursor.

system.profile.cursorid: O ID do cursor acessado pelas operações query e getmore .

system.profile.keysExamined

Alterado na versão 3,2,0.

Renomeado de system.profile.nscanned. O número de chaves de índice que o MongoDB verificou para realizar a operação.

Em geral, se keysExamined for muito maior do que nreturned, o banco de dados estará verificando muitas chaves de índice para localizar os documentos de resultado. Considere criar ou ajustar os índices para melhorar o desempenho da query.

Alterado na versão 3.4.

keysExamined está disponível para os seguintes comandos e operações:

system.profile.docsExamined

Alterado na versão 3,2,0: Renomeado de system.profile.nscannedObjects.

O número de documentos na coleção que o MongoDB digitalizou para realizar a operação.

Alterado na versão 3.4.

docsExamined está disponível para os seguintes comandos e operações:

system.profile.hasSortStage

Alterado na versão 3,2,0: Renomeado de system.profile.scanAndOrder.

hasSortStage é um booleano que é true quando uma query não pode utilizar o pedido no índice para retornar os resultados ordenados solicitados; isto é, O MongoDB deve classificar os documentos depois de recebê-los de um cursor. O campo só aparece quando o valor é true.

Alterado na versão 3.4.

hasSortStage está disponível para os seguintes comandos e operações:

system.profile.usedDisk

Novidades na versão 4.2.

Um booleano que indica se algum estágio de agregação gravou dados em arquivos temporários devido a restrições de memória.

Aparece apenas se usedDisk for verdadeiro.

system.profile.ndeleted: O número de documentos excluídos pela operação.

system.profile.ninserted: O número de documentos inseridos pela operação.

system.profile.nMatched: O número de documentos que correspondem à condição de querypara a operação de atualização.

system.profile.nModified: O número de documentos modificados pela operação de atualização.

system.profile.upsert: Um booleano que indica o valor da opção upsert da operação de atualização. Aparece apenas se upsert for verdadeiro.

system.profile.fromMultiPlanner

Novidades na versão 3.2.5.

Um booleano que indica se o planejador de queryavaliou vários planos antes de escolher o plano de execução vencedor para a query.

Somente presente quando o valor é true.

system.profile.replanned

Novidades na versão 3.2.5.

Um booleano que indica se o query removeu um plano armazenado em cache e reavaliou todos os planos candidatos.

Somente presente quando o valor é true.

system.profile.replanReason

Uma string que indica o motivo específico pelo qual um plano em cache foi removido.

Somente presente quando o valor de replanned for true.

system.profile.keysInserted: O número de chaves de índice inseridas para uma operação de gravação fornecida.

system.profile.keysDeleted

Removido em 3.4.

O número de chaves de índice que a atualização alterou na operação. Alterar uma chave de índice carrega um pequeno custo de desempenho, pois o reconhecimento de data center deve remover a chave antiga e inserir uma nova chave no índice B-tree.

system.profile.writeConflicts: O número de conflitos encontrados durante a operação de gravação; por exemplo, uma operação de update tenta modificar o mesmo documento que outra operação update . Consulte também conflito de escrita.

system.profile.numYield: O número de vezes que a operação cedeu para permitir a conclusão de outras operações. Normalmente, as operações rendem quando precisam de acesso a dados que o MongoDB ainda não leu totalmente na memória. Isso permite que outras operações que tenham dados na memória sejam concluídas enquanto o MongoDB lê os dados da operação de produção. Para obter mais informações, consulte as perguntas frequentes sobre quando as operações resultam.

system.profile.queryHash

Uma string hexadecimal que representa um hash da forma de query e depende somente da forma de query. queryHash pode ajudar a identificar queries lentas (incluindo o filtro de query de operações de gravação) com a mesma forma de query.

Observação

Como em qualquer função de hash, duas formas de query diferentes podem resultar no mesmo valor de hash. No entanto, a ocorrência de colisões de hash entre diferentes formas de query é improvável.

Para obter mais informações sobre queryHash e planCacheKey, consulte queryHash e planCacheKey.

Novidades na versão 4.2.

system.profile.planCacheKey

Um hash da chave para a entrada de cache do plano associada à query.

Ao contrário de queryHash, planCacheKey é uma função tanto da forma da consulta quanto dos índices atualmente disponíveis para essa forma. Ou seja, se os índices compatíveis com a forma da consulta forem adicionados/descartados, o valor planCacheKey poderá mudar, mas o valor queryHash não mudará.

Para obter mais informações sobre queryHash e planCacheKey, consulte queryHash e planCacheKey.

Novidades na versão 4.2.

system.profile.locks

O system.profile.locks fornece informações para vários tipos de bloqueio e modos de bloqueio mantidos durante a operação.

Os possíveis tipos de trava são:

Bloquear tipo	Descrição
`ParallelBatchWriterMode`	Representa um bloqueio para o modo de escrita em lote paralelo. Em versões anteriores, as informações do PBWM foram relatadas como parte das informações de bloqueio do `Global`.
`ReplicationStateTransition`	Representa o bloqueio obtido para transições de estado membro do conjunto de réplicas.
`Global`	Representa bloqueio global.
`Database`	Representa bloqueio de banco de dados.
`Collection`	Representa bloqueio de coleção.
`Mutex`	Representa mutex.
`Metadata`	Representa bloqueio de metadados.
`oplog`	Representa bloqueio no oplog.

Os possíveis modos de bloqueio para os tipos de bloqueio são os seguintes:

Modo de bloqueio	Descrição
`R`	Representa bloqueio compartilhado (S).
`W`	Representa bloqueio exclusivo (X).
`r`	Representa bloqueio de Intent Shared (IS).
`w`	Representa bloqueio Intent Exclusive (IX).

As informações de bloqueio devolvidas para os vários tipos de bloqueio incluem:

system.profile.locks.acquireCount: Número de vezes que a operação adquiriu a trava no modo especificado.

system.profile.locks.acquireWaitCount: Número de vezes que a operação teve que esperar pelas aquisições de bloqueio acquireCount porque os bloqueios foram mantidos em modo conflitante. acquireWaitCount é menor ou igual a acquireCount.

system.profile.locks.timeAcquiringMicros

Tempo cumulativo em microssegundos que a operação teve que esperar para adquirir as travas.

timeAcquiringMicros dividido por acquireWaitCount fornece um tempo médio aproximado de espera para o modo de bloqueio específico.

system.profile.locks.deadlockCount: O número de vezes que a operação encontrou impasses enquanto aguardava aquisições de trava.

Para obter mais informações sobre lock modes, consulte Que tipo de locking o MongoDB usa?.

system.profile.authorization

Novidades na versão 5.0.0.

O número de vezes que o cache do usuário é acessado para cada operação. Essas métricas só são exibidas quando uma operação acessa o cache do usuário pelo menos uma vez.

Essas métricas só estão disponíveis quando o log de operação lenta ou a criação de perfil de banco de dados está habilitada.

system.profile.authorization não está incluído na saída db.currentOp().

system.profile.authorization.startedUserCacheAcquisitionAttempts: O número de vezes que a operação tentou acessar o cache do usuário.

system.profile.authorization.completedUserCacheAcquisitionAttempts: O número de vezes que a operação recuperou os dados do usuário do cache do usuário.

system.profile.authorization.userCacheWaitTimeMicros: O tempo total que a operação gastou aguardando respostas de cache do usuário.

system.profile.storage

Novidade na versão 4.2: (Também disponível a partir de 4.0.9)

As informações do system.profile.storage fornecem métricas nos dados do mecanismo de armazenamento e tempo de espera para a operação.

Métricas de armazenamento específicas são retornadas somente se os valores forem maiores que zero.

system.profile.storage.data.bytesRead

Novidade na versão 4.2: (Também disponível a partir de 4.0.9)

Número de bytes lidos pela operação do disco para o cache.

A leitura de dados do disco no cache inclui tudo o que é necessário para executar a query. Se os dados já estiverem no cache, o número de bytes lidos do disco poderá ser 0.

O número de bytes lidos do disco inclui mais do que os documentos consultados:

O WiredTiger lê em unidades de páginas e uma página pode conter um ou vários documentos. Se um documento estiver em uma página, todos os documentos nessa página serão lidos no cache e incluídos no valor bytesRead.
Se o cache exigir gerenciamento de página (como remoção ou releituras), o valor bytesRead incluirá dados lidos do disco nessas operações.
Se o índice não estiver no cache ou se o índice no cache estiver obsoleto, o WiredTiger lerá várias páginas internas e de folha do disco para reconstruir o índice no cache.

system.profile.storage.data.timeReadingMicros: Novidade na versão 4.2: (Também disponível a partir de 4.0.9)
Tempo em microssegundos que a operação tinha que gastar para ler a partir do disco.

system.profile.storage.data.bytesWritten

Novidade na versão 4.2: (Também disponível a partir de 4.0.9)

Número de bytes gravados pela operação do cache para o disco.

O WiredTiger normalmente não exige que a queryseja gravada no disco. Os dados modificados pela query são gravados em um cache na memória que o WiredTiger libera para o disco como parte de uma operação de remoção ou checkpoint. Nesses casos, bytesWritten mostra como 0.

Se o thread que executa a query exigir gerenciamento de página forçado (como remoção), o WiredTiger gravará o conteúdo da página no disco. Essa liberação provavelmente inclui dados não relacionados às alterações feitas pela própria bytesWritten, o que pode fazer com que mostre um valor mais alto do que o esperado.

system.profile.storage.data.timeWritingMicros: Novidade na versão 4.2: (Também disponível a partir de 4.0.9)
Tempo em microssegundos que a operação teve que gastar para escrever no disco.

system.profile.storage.timeWaitingMicros.cache: Novidade na versão 4.2: (Também disponível a partir de 4.0.9)
Tempo em microssegundos que a operação teve que esperar por espaço no cache.

system.profile.storage.timeWaitingMicros.schemaLock: Novidade na versão 4.2: (Também disponível a partir de 4.0.9)
Tempo em microssegundos em que a operação (se estiver modificando o esquema) teve que esperar para adquirir um trava de esquema.

system.profile.storage.timeWaitingMicros.handleLock: Novidade na versão 4.2: (Também disponível a partir de 4.0.9)
Tempo em microssegundos que a operação teve que esperar para adquirir o trava nos manipuladores de dados necessários.

system.profile.nreturned: O número de documentos devolvidos pela operação.

system.profile.responseLength

O comprimento em bytes do documento de resultado da operação. Um responseLength grande pode afetar o desempenho. Para limitar o tamanho do documento de resultado de uma operação de query, você pode usar qualquer um dos métodos abaixo:

Observação

Quando o MongoDB grava informações de perfil de query no log, o valor responseLength está em um campo denominado reslen.

system.profile.protocol: O formato de mensagem de solicitação do MongoDB Wire Protocol.

system.profile.millis: O tempo em milésimos de segundo da perspectiva do mongod desde o início da operação até o final da operação.

system.profile.planSummary: Novidade na versão 3.4.
Um resumo do plano de execução.

system.profile.execStats

Um documento que contém as estatísticas de execução da operação de query. Para outras operações, o valor é um documento vazio.

O system.profile.execStats apresenta as estatísticas como uma árvore; cada nó fornece as estatísticas para a operação executada durante esse estágio da operação de query.

Observação

A lista de os campos a seguir para execStats não tem a intenção de ser exaustiva, pois os campos os campos retornados variam de acordo com o estágio.

system.profile.execStats.stage

O nome descritivo da operação executada como parte da execução da query; por exemplo,

COLLSCAN para uma verificação de collection
IXSCAN para varredura de chaves de índice
FETCH para recuperar documentos

system.profile.execStats.inputStages: Uma array que contém estatísticas para as operações que são os estágios de entrada do estágio atual.

system.profile.ts: O timestamp da operação.

system.profile.client: O endereço IP ou nome de host da conexão do cliente onde a operação se origina.

system.profile.appName: Novidade na versão 3.4.
O identificador do aplicativo cliente que executou a operação. Use uma opção appName de connection string para definir um valor personalizado para o campo appName.

system.profile.allUsers: Uma array de informações de usuário autenticadas (nome de usuário e banco de dados de dados) para a sessão. Consulte também Usuários em implementações autogerenciadas.

system.profile.user: O usuário autenticado que executou a operação. Se a operação não foi executada por um usuário autenticado, o valor deste campo é uma string vazia.

Voltar

Database Profiler

Otimizar o desempenho

Observação

Aviso

Documento de system.profile exemplo

Referência de saída

Observação

Observação

Observação

Observação

Documento de `system.profile` exemplo