Perguntas sobre o ajuste de desempenho do MongoDB
Avalie esse Artigo
Para resolver a maioria dos desafios relacionados a manter um MongoDB cluster funcionando em alta velocidade, basta se fazer algumas perguntas fundamentais e, em seguida, usar certas métricas essenciais para respondê-las.
Observando as métricas relacionadas ao desempenho da query, ao desempenho do banco de dados, à taxa de transferência, à utilização de recursos, à saturação de recursos e a outros erros críticos de "assertion", é possível encontrar problemas que podem estar ocultos em seu cluster. Detectar esses problemas com antecedência ajuda você a resolvê-los antes que eles afetem o desempenho.
Essas perguntas fundamentais se aplicam independentemente de como o MongoDB é usado, seja por meio do MongoDB Atlas, o serviço gerenciado disponível em todos os principais provedores de nuvem, ou por meio das edições MongoDB Community ou Enterprise, que são executadas de forma autogerenciada no local ou na nuvem.
É possível usar cada tipo de implantação do MongoDB para estruturar bancos de dados sob medida com enormes volumes de transação, então o ajuste de desempenho precisa ser uma atividade constante.
Mas a boa notícia é que as mesmas métricas são usadas no processo de ajuste, independentemente de como o MongoDB é usado.
No entanto, como veremos, o processo de ajuste é muito mais fácil na nuvem usando o MongoDB Atlas, onde tudo é mais automático e pré-fabricado.
Aqui estão as principais perguntas que você sempre deve fazer sobre o ajuste de desempenho do MongoDB e as métricas que podem respondê-las.
Os problemas de consulta talvez sejam o menor problema quando se trata de depurar problemas de desempenho do MongoDB. Encontrar problemas e corrigi-los geralmente é simples. Esta seção aborda as métricas que podem revelar problemas de desempenho de query e o que fazer se você encontrar queries lentas.
Log de query lenta. O tempo decorrido e o método usado para executar cada query são registrados em arquivos de log do MongoDB, então é possível pesquisar esses arquivos para encontrar queries lentas. Além disso, queries acima de um determinado limite podem ser registradas de forma específica pelo Profiler de banco de dados do MongoDB.
- Quando uma query está lenta, primeiro verifique se foi uma verificação de coleção em vez de uma verificação de índice.
- Com as verificações de coleção, todos os documentos de uma coleção são lidos.
- As verificações de índice limitam o número de documentos que devem ser inspecionados.
- Mas lembre-se: os índices têm um custo quando se trata de gravações e atualizações. Muitos índices subutilizados podem atrasar a modificação ou inserção de novos documentos. Dependendo da natureza de suas cargas de trabalho, isso pode ser um problema ou não.
Digitalizado vs retornado é uma métrica que pode ser encontrada no Cloud Manager e no MongoDB Atlas que indica quantos documentos tiveram que ser digitalizados para retornar os documentos que atendem à query.
- Na ausência de índices, um ideal raramente atendido para essa proporção é 1/1, o que significa que todos os documentos digitalizados foram devolvidos - nenhuma digitalização desperdiçada. No entanto, na maioria das vezes, quando a digitalização é concluída, os documentos são digitalizados que não retornam, o que significa que a proporção é maior que 1.
- Quando os índices são usados, essa taxa pode ser menor que 1 ou até mesmo 0, o que significa que você tem uma query abrangida. Se nenhum documento precisava ser verificado, a proporção de 0 significa que todos os dados necessários estavam no índice.
- A verificação de grandes quantidades de documentos é ineficiente e pode indicar problemas relacionados à falta de índices ou indicar a necessidade de otimização da query.
Scan and Order é uma métrica relacionada ao índice que está disponível no Cloud Manager e no MongoDB Atlas.
- Um número alto de Scan and Order, digamos 20 ou mais, indica que o servidor precisa classificar os resultados da query para colocá-los na ordem correta. Isso leva tempo e aumenta a carga de memória no servidor.
- Corrija isso garantindo que os índices sejam classificados na ordem em que as queries precisam dos documentos ou adicionando índices ausentes.
O WiredTiger Ticket Number é um indicador essencial do desempenho do storage engine do WiredTiger, que, desde a versão 3.2 tem sido o storage engine do MongoDB.
- O WiredTiger tem um conceito de tickets de leitura ou gravação que são criados quando o banco de dados é acessado. O número do ticket do WiredTiger deve estar sempre em 128.
- Se o valor ficar abaixo de 128 e se mantiver abaixo desse número, isso significa que o servidor está esperando algo e é um indício de um problema.
- Então, a solução é encontrar as operações que estão sendo executadas muito lentamente e iniciar um processo de depuração.
- Implantações do MongoDB que usam versões anteriores a 3.2 com certeza apresentarão um aumento de desempenho ao migrar para uma versão posterior que usa o WiredTiger.
Os antipadrões da estrutura do documento não são revelados por uma métrica, mas podem ser algo a se procurar ao depurar queries lentas. Aqui estão duas das mais conhecidas más práticas que prejudicam o desempenho.
Arrays ilimitadas: em um documento do MongoDB, se uma array puder aumentar sem um limite de tamanho, isso poderá causar um problema de desempenho, porque sempre que você a atualizar, o MongoDB precisará gravá-la de novo no documento. Se a array for enorme, isso poderá causar um problema de desempenho. Saiba mais em Evitar arrays ilimitadas e Práticas recomendadas de desempenho: padrões de query e criação de perfil.
Subdocumentos sem limites: o mesmo pode acontecer com relação aos subdocumentos. O MongoDB permite inserir documentos dentro de documentos, com até 128 níveis de aninhamento. Cada documento do MongoDB, inclusive os subdocumentos, também tem um limite de tamanho de 16 MB. Se o número de subdocumentos ficar grande demais, poderão ocorrer problemas de desempenho.
Uma solução comum para esse problema é mover alguns ou todos os subdocumentos para uma coleção separada e, em seguida, fazer referência a eles no documento original. Você pode saber mais sobre esse tópico nesta postagem do blog.
O MongoDB, como a maioria dos sistemas de banco de dados avançados, tem milhares de métricas que monitoram todos os aspectos do desempenho do banco de dados, como a leitura, a gravação e a query do banco de dados, além de garantir que tarefas de manutenção em segundo plano, como backups, não atrapalhem o funcionamento.
Todas as métricas descritas nesta seção indicam problemas maiores que podem ter várias causas. Como uma luz de advertência em um painel, essas métricas são indicadores de alto nível que ajudam você a começar a procurar as causas antes que o banco de dados tenha uma falha catastrófica.
Observação: são abordadas várias maneiras de acessar todas essas métricas na seção Obter acesso às métricas e configurar o monitoramento abaixo.
A atraso de replicação ocorre quando um membro secundário de um conjunto de réplicas fica atrás do primário. Uma análise detalhada das métricas relacionadas ao OpLog pode ajudar a chegar à raiz dos problemas, mas as causas geralmente são:
- Um problema de rede entre o primário e o secundário, tornando os nós inacessíveis
- Um nó secundário que aplica dados de forma mais lenta do que o nó primário
- Capacidade de gravação insuficiente; nesse caso, você deve adicionar mais fragmentos
- Operações lentas no nó primário, bloqueando a replicação
Problemas de desempenho de bloqueio são indicados quando o restante dos tickets de leitura ou gravação disponíveis chega a zero, o que significa que novas solicitações de leitura ou gravação ficarão na fila até que um novo ticket de leitura ou gravação esteja disponível.
- O sistema de bloqueio interno do MongoDB é usado para permitir queries simultâneas, além de evitar conflitos de gravação e leituras inconsistentes.
- Problemas de desempenho de bloqueio podem indicar uma variedade de problemas, incluindo índices abaixo do ideal e padrões de projeto de esquema ruins, que podem fazer com que os bloqueios sejam mantidos por mais tempo do que o necessário.
O aumento do número de cursores abertos sem um crescimento correspondente do tráfego costuma ser sintoma de queries mal indexadas ou o resultado de queries de longa duração devido a grandes conjuntos de resultados.
- Essa métrica pode ser outro indicador de que o tipo de técnica de otimização de query mencionado na primeira seção está correto.
Uma grande parte do ajuste de desempenho é reconhecer quando seu tráfego total, a taxa de transferência de transações no sistema, está aumentando além da capacidade planejada do seu cluster. Ao acompanhar o crescimento da taxa de transferência, é possível expandir a capacidade de forma ordenada. Aqui estão as métricas a serem monitoradas.
Operações de leitura e gravação é a métrica fundamental que indica quanto trabalho é feito pelo cluster. A proporção de leituras e gravações depende muito da natureza das cargas de trabalho em execução no cluster.
- O monitoramento das operações de leitura e gravação ao longo do tempo permite estabelecer faixas e limites normais.
- À medida que as tendências nas operações de leitura e gravação mostram crescimento na taxa de transferência, a capacidade deve ser aumentada gradualmente.
Métricas de Documentos e Executor de Query são boas indicações de que o cluster está realmente muito ocupado. Essas métricas podem ser encontradas no Cloud Manager e no MongoDB Atlas. Assim como ocorre com as operações de leitura e gravação, não há um número certo ou errado para essas métricas, mas ter uma boa ideia do que é normal ajuda a discernir se o baixo desempenho é decorrente do grande tamanho da carga de trabalho ou se pode ser atribuído a outros motivos.
- As métricas do documento são atualizadas sempre que você devolve ou insere um documento. Quanto mais documentos forem devolvidos, inseridos, atualizados ou excluídos, mais ocupado estará seu cluster.
- O baixo desempenho em um cluster que tem muita capacidade geralmente aponta para problemas de query.
- O executor de query informa quantas queries estão sendo processadas por meio de dois pontos de dados:
- Verificado - a taxa média por segundo durante o período de amostragem selecionado de itens de índice verificados durante queries e avaliação do plano de query.
- Objetos verificados - taxa média por segundo durante o período de amostragem selecionado de documentos verificados durante queries e avaliação do plano de query.
As métricas de hardware e rede podem ser indicações importantes de que a taxa de transferência está aumentando e excederá a capacidade da infraestrutura de computação. Essas métricas são coletadas do sistema operacional e da infraestrutura de rede. Para que essas métricas sejam úteis para fins de diagnóstico, você deve ter uma noção do que é normal.
- No MongoDB Atlas, ou ao usar o Cloud Manager, essas métricas são facilmente exibidas. Se você estiver executando em uma instalação física, isso depende do seu sistema operacional.
- Há muito o que acompanhar, mas tenha no mínimo uma linha de base para métricas como:
- Latência do disco
- IOPS de Disco
- Número de conexões
Um MongoDB cluster faz uso de uma variedade de recursos fornecidos pela infraestrutura subjacente de computação e rede. Esses recursos podem ser monitorados de dentro do MongoDB, bem como de fora do MongoDB no nível da infraestrutura de computação, conforme descrito na seção anterior. Aqui estão os recursos cruciais que podem ser facilmente monitorados de dentro do mongo, especialmente por meio do Cloud Manager e do MongoDB Atlas.
O número atual de conexões de cliente geralmente é uma métrica eficaz para indicar a carga total em um sistema. Manter o controle dos intervalos normais em vários momentos do dia ou da semana pode ajudar a identificar rapidamente os picos no tráfego.
- Uma métrica relacionada, a porcentagem de conexões usadas, pode indicar quando o MongoDB está perto de ficar sem conexões disponíveis.
As métricas de armazenamento monitoram como o MongoDB está usando o armazenamento permanente. No storage engine WiredTiger, cada coleção é um arquivo, e cada índice também. Quando um documento em uma coleção é atualizado, todo o documento é reescrito.
- Se as métricas de espaço de memória (dataSize, indexSize ou storageSize) ou o número de objetos mostrarem uma mudança inesperada significativa enquanto o tráfego do banco de dados permanecer dentro dos intervalos normais, isso poderá indicar um problema.
- Uma queda repentina no dataSize pode indicar uma grande quantidade de exclusão de dados, que deve ser rapidamente investigada se não for esperada.
As métricas de memória mostram como o MongoDB está usando a memória virtual da infraestrutura de computação que hospeda o cluster.
- Um número crescente de falhas de página ou uma quantidade cada vez maior de dados sujos (dados alterados, mas ainda não gravados em disco) podem indicar problemas relacionados à quantidade de memória disponível para o cluster.
- As métricas de cache podem ajudar a determinar se o conjunto de trabalho está superando o cache disponível.
As asserções do MongoDB são documentos criados, quase sempre devido a um erro, que são registrados como parte do processo de log do MongoDB.
- O monitoramento do número de asserções criadas em vários níveis de gravidade pode fornecer uma indicação primária de problemas inesperados. As asserções podem ser erros de mensagem (o tipo mais sério) ou asserções de aviso, asserções regulares e asserções de usuário.
- Examinar as afirmações pode fornecer pistas que podem levar à descoberta de problemas.
Fazer uso de métricas é muito mais fácil se você conhece bem os dados: de onde eles vêm, como chegar a eles e o que significam.
Com a evolução da plataforma MongoDB, ficou muito mais fácil monitorar clusters e resolver problemas comuns. Além disso, o monitoramento e a análise do ajuste de desempenho tornaram-se cada vez mais automatizados. Por exemplo, o MongoDB Atlas, por meio do Performance Advisor, agora sugere a adição de índices se detectar um problema de desempenho de query.
Mas é melhor conhecer toda a história dos dados, não apenas os gráficos bonitos produzidos no final.
As fontes de métricas usadas para monitorar o MongoDB são os logs criados quando o MongoDB está em execução e os comandos que podem ser executados dentro do sistema do MongoDB. Esses comandos produzem estatísticas detalhadas que descrevem o estado do sistema.
O monitoramento de métricas de desempenho do MongoDB (WiredTiger) contém uma ótima categorização das métricas disponíveis para diferentes finalidades e os comandos que podem ser usados para obtê-las. Esses comandos fornecem uma imensa quantidade de informações detalhadas em forma bruta que é semelhante a esta captura de tela:
Estas informações são de alta qualidade, mas difíceis de usar.
À medida que o MongoDB amadureceu como plataforma, foram criadas interfaces especializadas para reunir as métricas mais úteis.
- O Ops Manager é uma plataforma de gerenciamento de implantações locais e de nuvem privada do MongoDB que inclui recursos abrangentes de monitoramento e alerta.
- Cloud Manager é uma plataforma de gerenciamento para implantações na nuvem autogerenciadas do MongoDB que também inclui amplas funcionalidades de monitoramento e alerta. (Lembre-se de que esta captura de tela reflete a interface do usuário no momento da escrita.)
- O Painel de Desempenho em Tempo Real, parte do MongoDB Atlas ou do MongoDB Ops Manager (exige a assinatura do MongoDB Enterprise Advanced), fornece visualizações de gráficos ou tabelas de dezenas de métricas e é uma ótima maneira de acompanhar muitos aspectos do desempenho, inclusive a maioria das métricas abordadas anteriormente.
- Produtos comerciais como New Relic, Sumo Logic e DataDog fornecem interfaces criadas para monitorar e emitir alertas sobre MongoDB clusters. Diversas plataformas de código aberto, como mtools, também podem ser usadas.
O MongoDB Atlas aproveitou as API padronizadas e as enormes quantidades de dados disponíveis em nuvem para abrir novos caminhos na automatização do ajuste de desempenho. Além do Painel de Desempenho em Tempo Real mencionado acima, o Performance Advisor do MongoDB Atlas analisa as queries que você realmente aplicou aos seus dados, determina o que está lento e o que não está e faz recomendações sobre quando adicionar índices que levam em conta os índices já em uso.
De certa forma, as perguntas abordadas neste artigo representam um manual para executar um processo de ajuste de desempenho. Se já estiver realizando esse processo, talvez você tenha tido algumas ideias novas com base na análise.
Recursos como este artigo podem ajudar você a atingir ou refinar seus objetivos se você souber as perguntas a serem feitas e alguns métodos para alcançá-los. Mas se você não souber o que perguntar nem quais etapas seguir, é melhor evitar a abordagem de "tentativa e erro" e falar com alguém com experiência. Tendo ampla experiência em ajustar grandes implantações do MongoDB, os serviços profissionais podem ajudar a identificar as etapas mais eficazes para melhorar o desempenho imediatamente.
Depois que os problemas imediatos forem resolvidos, os serviços profissionais poderão orientar você na criação de um processo contínuo e simplificado de ajuste de desempenho para acompanhar as métricas importantes para sua implantação e tomar medidas com base nelas.
Esperamos que este artigo tenha deixado claro que, com uma certa dose de esforço, é possível manter seu MongoDB cluster impecável. Não importa que tipos de volumes de trabalho estejam em execução ou onde a implantação esteja localizada, use as ideias e ferramentas mencionadas acima para saber o que está acontecendo no seu cluster e resolver problemas de desempenho antes que eles se tornem perceptíveis ou causem grandes interrupções.
Avalie esse Artigo