Solução de Problemas e Depuração do MongoDB
Quais são os primeiros passos que você toma quando uma aplicação MongoDB está com desempenho lento?
Resposta:
Primeiro, verificaria os logs do MongoDB em busca de erros ou consultas lentas. Em seguida, usaria mongostat e mongotop para monitorar métricas de desempenho em tempo real e identificar operações ativas ou coleções que consomem recursos. Finalmente, analisaria db.currentOp() para ver as operações em andamento.
Como você identifica consultas de execução lenta no MongoDB?
Resposta:
Eu uso o comando db.setProfilingLevel(1, { slowms: 100 }) para habilitar a profilagem do banco de dados, que registra consultas que excedem um limite especificado. Alternativamente, posso usar db.system.profile.find() para consultar diretamente a coleção do profiler em busca de operações lentas. O plano explain() também é crucial para entender a execução da consulta.
Uma consulta está consistentemente lenta. Que ferramentas e técnicas você usaria para otimizá-la?
Resposta:
Eu usaria explain('executionStats') para analisar o plano de consulta, identificar índices ausentes ou estágios ineficientes. Com base na saída do explain, eu criaria índices apropriados. Se a indexação não for suficiente, eu consideraria redesenho do esquema ou reestruturação da consulta.
Como você soluciona a alta utilização de CPU em um servidor MongoDB?
Resposta:
Alta CPU geralmente indica consultas ineficientes, índices ausentes ou operações de escrita excessivas. Eu verificaria mongostat para operações ativas, db.currentOp() para processos de longa duração e o profiler para consultas lentas. Ferramentas de nível de sistema operacional como top ou htop também podem identificar o uso de CPU do processo mongod.
Quais são as causas comuns de alto uso de memória no MongoDB e como você as aborda?
Resposta:
Alto uso de memória pode ser devido a grandes conjuntos de trabalho (working sets), consultas ineficientes que puxam muitos dados para a RAM, ou pipelines de agregação não otimizados. Eu verificaria db.serverStatus().wiredTiger.cache para utilização do cache e garantiria a indexação adequada para reduzir os dados escaneados. Pode ser necessário escalar a RAM ou implementar sharding.
Descreva como você depuraria um conjunto de réplicas que não está sincronizando corretamente.
Resposta:
Eu começaria verificando rs.status() em todos os membros para identificar o estado e a saúde de cada nó. Em seguida, examinaria os logs do MongoDB em cada membro em busca de erros relacionados à replicação, problemas de rede ou falhas na aplicação do oplog. A conectividade de rede entre os membros também é um culpado comum.
Qual é o propósito do profiler do MongoDB e como você o habilita?
Resposta:
O profiler do MongoDB captura informações detalhadas sobre operações de banco de dados, incluindo tempos de execução de consultas, locks e I/O. Ele ajuda a identificar consultas e operações lentas. Você o habilita usando db.setProfilingLevel(level, { slowms: threshold }), onde level pode ser 0 (desligado), 1 (operações lentas) ou 2 (todas as operações).
Como você lida com uma situação em que uma instância do MongoDB fica sem espaço em disco?
Resposta:
Primeiro, eu identificaria o que está consumindo espaço usando db.stats() e db.collection.stats(). Em seguida, procuraria por arquivos de log grandes ou backups antigos para excluir. Se o crescimento dos dados for o problema, eu consideraria adicionar mais espaço em disco, implementar sharding ou arquivar dados antigos para reduzir o conjunto de trabalho.
Você suspeita de uma operação com deadlock. Como você investigaria isso no MongoDB?
Resposta:
O MongoDB usa controle de concorrência otimista, então deadlocks verdadeiros são raros. No entanto, operações de longa duração que detêm locks podem bloquear outras. Eu usaria db.currentOp() para identificar operações com o status waitingForLock e ver qual operação está detendo o lock. Eu poderia então terminar a operação bloqueadora, se necessário.
Quais são as métricas-chave que você monitora para a saúde e desempenho do MongoDB?
Resposta:
As métricas-chave incluem opcounters (leituras, escritas, comandos), connections (atuais, disponíveis), network (bytes de entrada/saída), memory (residente, virtual, mapeada), wiredTiger.cache (bytes sujos, páginas lidas/escritas) e locks (global, banco de dados, coleção). Estes fornecem insights sobre a carga de trabalho e a utilização de recursos.