Página inicial do Docs → Desenvolver aplicações → Manual do MongoDB
Desempenho do MongoDB
Nesta página
Ao desenvolver e operar aplicativos com o MongoDB, talvez seja necessário analisar o desempenho do aplicativo e de seu banco de dados. Quando você encontra um desempenho degradado, geralmente é por causa das estratégias de acesso ao banco de dados, da disponibilidade do hardware e do número de conexões abertas ao banco de dados.
Alguns usuários podem enfrentar limitações de desempenho como resultado de estratégias de indexação inadequadas ou inapropriadas, ou como consequência de padrões de design de esquema ruins. Desempenho de trava explica como isso pode impactar as travas internas do MongoDB.
Problemas de desempenho podem indicar que o banco de dados está operando na capacidade e que é hora de adicionar capacidade adicional ao banco de dados. Em particular, o conjunto de trabalho do aplicativo deve caber na memória física disponível.
Em alguns casos, os problemas de desempenho podem ser temporários e relacionados a uma carga anormal de tráfego. Conforme discutido em Número de conexões, o dimensionamento pode ajudar a reduzir o tráfego excessivo.
A criação de perfil de banco de dados pode ajudar você a entender quais operações estão causando degradação.
Desempenho de trava
O MongoDB usa um sistema de bloqueio para garantir a consistência do conjunto de dados. Se determinadas operações durarem muito tempo ou se formar uma fila, o desempenho diminuirá à medida que as solicitações e operações aguardarem a trava.
As desacelerações relacionadas ao bloqueio podem ser intermitentes. Para ver se o bloqueio está afetando seu desempenho, consulte a seção de bloqueios e a seção globalLock da saída doserverStatus.
Dividir locks.<type>.timeAcquiringMicros por locks.<type>.acquireWaitCount pode fornecer um tempo médio aproximado de espera para um modo de bloqueio específico.
locks.<type>.deadlockCount fornece o número de vezes que as aquisições de trava encontraram imprevistos.
Se globalLock.currentQueue.total for consistentemente alto, então há uma chance de que um grande número de solicitações esteja aguardando uma trava. Isso indica um possível problema de simultaneidade que pode estar afetando o desempenho.
Se globalLock.totalTime for alto em relação a uptime, o banco de dados existiu em um estado de bloqueio por um período significativo de tempo.
Consultas longas podem resultar do uso ineficaz de índices; projeto de esquema não ótimo; estrutura de consulta deficiente; problemas de arquitetura de sistemas; ou RAM insuficiente, resultando em leituras de disco.
Número de conexões
Em alguns casos, o número de conexões entre os aplicativos e o banco de dados pode sobrecarregar a capacidade do servidor de lidar com as solicitações. Os seguintes campos no documento serverStatus podem fornecer informações:
connectionsé um contêiner para os dois campos a seguir:connections.currento número total de clientes atuais conectados à instância do banco de dados.connections.availableo número total de conexões não utilizadas disponíveis para novos clientes.
Se houver inúmeras solicitações de aplicação simultâneas, o reconhecimento de data center poderá ter problemas para acompanhar a demanda. Se esse for o caso, você precisará aumentar a capacidade de sua implantação.
Para aplicativos com gravação pesada, implemente fragmentação e adicione um ou mais fragmentos a um cluster fragmentado para distribuir a carga entre as instâncias de mongod .
Os picos no número de conexões também podem ser o resultado de erros no aplicativo ou no driver. Todos os drivers MongoDB oficialmente suportados implementam o pool de conexões, o que permite que os clientes usem e reutilizem conexões com mais eficiência. Um número extremamente alto de conexões, particularmente sem volume de trabalho correspondente, geralmente é indicativo de um erro de driver ou de outra configuração.
A menos que seja restringido por limites de todo o sistema, o número máximo de conexões de entrada suportadas pelo MongoDB é configurado com a definição maxIncomingConnections. Nos sistemas baseados em Unix, os limites de todo o sistema podem ser modificados usando o comando ulimit ou editando o arquivo /etc/sysctl do sistema. Consulte Configurações do UNIX ulimit para obter mais informações.
Análise de banco de dados
O analisador de banco de dados coleta informações detalhadas sobre as operações executadas em uma instância do mongod. O resultado do analisador pode ajudar a identificar queries e operações ineficientes.
Você pode habilitar e configurar o analisador para reconhecimento de data center individuais ou para todos os reconhecimento de data center em uma instância do mongod . As configurações do analisador afetam apenas uma única instância mongod e não se propagam em um conjunto de réplicas ou cluster fragmentado.
Consulte analisador de banco de dados para obter informações sobre como habilitar e configurar o analisador.
Os seguintes níveis de analisador estão disponíveis:
Nível | Descrição |
|---|---|
0 | O analisador está desligado e não coleta dados.
Este é o nível do analisador padrão. |
1 | |
2 | O analisador coleta dados para todas as operações. |
Aviso
A análise pode degradar o desempenho e expor dados de query não criptografados no registro do sistema. Considere cuidadosamente quaisquer implicações de desempenho e segurança antes de configurar e habilitar o analisador em um sistema de produção.
Consulte Sobrecarga do criador de perfil para obter mais informações sobre a possível degradação do desempenho.
Observação
Quando logLevel é definido como 0, o MongoDB registra operações lentas no log de diagnóstico a uma taxa determinada por slowOpSampleRate.
Em configurações logLevel mais altas, todas as operações aparecem no registro de diagnóstico, independentemente da latência, com a seguinte exceção: o registro de mensagens de entrada lentas do oplog pelos secundários. Os secundários registram apenas as entradas lentas do oplog; aumentar o logLevel não registra todas as entradas do oplog.
A partir do MongoDB 4.2, as entradas do criador de perfil e as mensagens de registro de diagnóstico (ou seja, mensagens de registro mongod/mongos) para operações de leitura/gravação incluem:
queryHashpara ajudar a identificar queries lentas com a mesma forma de query.planCacheKeypara fornecer mais informações sobre o cache do plano de consulta para queries lentas.
Captura de dados de diagnóstico em tempo integral
Para ajudar os engenheiros do MongoDB a analisar o comportamento do servidor, os processos mongod e mongos incluem um mecanismo de captura de dados de diagnóstico em tempo integral (FTDC). O FTDC está habilitado por padrão. Devido à sua importância na depuração de sistemas, as falhas de thread do FTDC são fatais e interrompem o processo pai mongod ou mongos.
Importante
Privacidade do FTDC
Os Data Federation FTDC são compactados e não podem ser lidos por humanos. Os engenheiros da MongoDB Inc. não podem acessar dados FTDC sem permissão explícita e assistência de proprietários ou operadores do sistema.
Os dados do FTDC nunca contêm nenhuma das seguintes informações:
Amostras de consultas, predicados de consulta ou resultados de consulta
Dados amostrados de qualquer collection ou índice de usuário final
Credenciais de usuário do sistema ou MongoDB ou certificados de segurança
Os dados do FTDC contêm determinadas informações da máquina host, como nomes de host, informações do sistema operacional e as opções ou configurações usadas para iniciar o mongod ou mongos. Essas informações podem ser consideradas protegidas ou confidenciais por algumas organizações ou órgãos reguladores, mas normalmente não são consideradas Informações de Identificação Pessoal (PII). Para clusters onde esses campos foram configurados com dados protegidos, confidenciais ou PII, notifique os engenheiros da MongoDB Inc. antes de enviar os dados FTDC para que as medidas apropriadas possam ser tomadas.
O FFTDC coleta periodicamente estatísticas produzidas pelos seguintes comandos:
replSetGetStatus(mongodapenas)collStatspara a collectionlocal.oplog.rs(mongodsomente)connPoolStats(mongosapenas)
Dependendo do sistema operacional do host, os dados de diagnóstico podem incluir uma ou mais das seguintes estatísticas de utilização:
Utilização da CPU
Utilização da memória
Utilização de disco relacionada ao desempenho. FTDC não inclui dados relacionados à capacidade de armazenamento.
Estatísticas de desempenho da rede. O FTDC captura apenas metadados e não captura ou inspeciona nenhum pacote de rede.
Observação
Se o processo mongod for executado em um container, o FTDC relatará as estatísticas de utilização da perspectiva do container em vez do sistema operacional host. Por exemplo, se o mongod for executado em um contêiner configurado com restrições de RAM, o FTDC calculará a utilização da memória em relação ao limite de RAM do contêiner, em vez do limite de RAM do sistema operacional host.
FTDC coleta estatísticas produzidas pelos seguintes comandos na rotação ou inicialização do arquivo:
Os processos mongod armazenam arquivos de dados FTDC em um diretório diagnostic.data nas instâncias storage.dbPath. Todos os arquivos de dados de diagnóstico são armazenados neste diretório. Por exemplo, dado um dbPath de /data/db, o diretório de dados de diagnóstico seria /data/db/diagnostic.data.
Os processos mongos armazenam arquivos de dados FTDC em um diretório de diagnóstico relativo à configuração do caminho de log systemLog.path . O MongoDB trunca a extensão de arquivo do caminho de log e concatena o diagnostic.data para o nome restante. Por exemplo, dada uma configuração path de /var/log/mongodb/mongos.log, o diretório de dados de diagnóstico seria /var/log/mongodb/mongos.diagnostic.data.
O FTDC é executado com os seguintes padrões:
Captura de dados a cada 1 segundo
Tamanho máximo da pasta
diagnostic.datade 200 MB.
Esses padrões são projetados para fornecer dados úteis aos engenheiros da MongoDB Inc. com impacto mínimo no desempenho ou no tamanho do armazenamento. Esses valores só exigem modificações se solicitados pelos engenheiros da MongoDB Inc. para fins específicos de diagnóstico.
Você pode visualizar o código-fonte do FTDC no repositório do MongoDB no Github . Os ftdc_system_stats_*.ccp arquivos definem especialmente quaisquer dados de diagnóstico específicos capturados do sistema.
Para desativar o FTDC, inicie o mongod ou mongos com a opção diagnosticDataCollectionEnabled: false especificada para a configuração setParameter no seu arquivo de configuração:
setParameter: diagnosticDataCollectionEnabled: false
A desativação do FTDC pode aumentar o tempo ou os recursos necessários para analisar ou depurar problemas com o suporte dos engenheiros da MongoDB Inc.