A utilização da CPU é uma métrica de monitoramento crítica para uma instância do ApsaraDB for MongoDB. O uso excessivo da CPU torna as respostas do MongoDB mais lentas e pode até mesmo indisponibilizar seus services. Este tópico descreve como visualizar a utilização da CPU de uma instância, as causas comuns de alto consumo e as estratégias de otimização.
Como visualizar a utilização da CPU
Visualizar gráficos de monitoramento: Na página Monitoring Information do console do ApsaraDB for MongoDB, visualize a utilização da CPU da sua instância do ApsaraDB for MongoDB. Para obter mais informações sobre a granularidade de coleta e o procedimento, consulte basic monitoring.
O ApsaraDB for MongoDB oferece diversas combinações de nós para arquiteturas de instâncias. Selecione um nó para visualizar sua utilização de CPU.
Instâncias de replica set: Uma instância de replica set consiste em um nó primário, um ou mais nós secundários, um nó oculto e um ou mais nós opcionais somente leitura.
Na arquitetura de cluster com sharding, o uso de CPU de cada shard equivale ao de um replica set. O Configserver armazena apenas metadados de configuração e raramente causa gargalo de CPU; portanto, geralmente você pode ignorá-lo. A utilização da CPU nos nós de roteamento Mongos depende principalmente dos conjuntos de resultados de agregação e do número de requisições simultâneas.
A utilização da CPU também varia conforme as especificações da instância. Por exemplo, se uma instância possui 8 núcleos de CPU e 16 GB de memória e atinge 100% de utilização, isso significa que os 8 núcleos foram totalmente consumidos. Nesse caso, a utilização é exibida como 100%, e não como 800%.
Causas comuns
Documentos verificados em excesso
O ApsaraDB for MongoDB suporta multithreading. Se uma única consulta precisar verificar um grande volume de documentos, a thread responsável pela execução ocupará recursos da CPU por um período prolongado. Quando há alta concorrência de requisições pendentes ou consultas que exigem a verificação massiva de documentos, ocorre elevada utilização da CPU na instância onde essas consultas são executadas. Existe uma relação direta entre a utilização da CPU e o total de documentos verificados na instância. Consultas que frequentemente precisam examinar muitos documentos são comuns nos seguintes cenários:
-
Varredura completa da coleção
Se você encontrar a palavra-chave
COLLSCANno log de consultas lentas ou na coleção system.profile, significa que uma consulta realizou uma varredura completa na coleção. Ative o profiler do banco de dados para utilizar a coleção system.profile. Para mais detalhes sobre como visualizar logs de consultas lentas e usar o profiler, consulte Slow query logs.Para saber mais sobre como interpretar planos de execução de consultas, veja Explain Results e Cursor Methods.
-
Design e uso inadequado de índices
Preste muita atenção em qualquer consulta executada frequentemente cujo valor de
docsExamined(número de documentos verificados) ultrapasse 1.000. Além da varredura completa da coleção, as situações abaixo podem resultar em um valor alto dedocsExamined:Uso de múltiplas condições de filtro sem um índice composto ou sem respeitar o princípio de correspondência de prefixo.
Consultas complexas ou com muitas operações de agregação, resultando em políticas de parsing ineficientes ou índices impossíveis de otimizar.
Avaliação incorreta da seletividade de dados de um campo e sua frequência de execução, impedindo que se alcance o melhor custo-benefício.
Concorrência excessiva
O envio de um grande volume de requisições de service com concorrência extremamente alta eleva a utilização da CPU. Para resolver esse problema, adicione núcleos de CPU caso confirme que não há problemas nas consultas.
Embora uma instância suporte um número máximo elevado de conexões totais, sua capacidade de processar conexões ativas é limitada pelos núcleos de CPU disponíveis. Quando as conexões ativas superam a quantidade de núcleos, a disputa por recursos provoca enfileiramento de threads e acúmulo de tarefas. Isso gera respostas lentas mesmo quando o monitoramento indica uma utilização geral baixa da CPU.
Outras causas
Criação de muitas conexões de curta duração. Nas versões posteriores ao MongoDB 3.X, o mecanismo padrão de autenticação é o SCRAM-SHA1, que exige operações intensivas de CPU, como cálculo de hash. Se houver alta concorrência de conexões efêmeras, o cálculo de hash consome recursos multiplicados da CPU, podendo esgotá-los completamente. Nessa situação, os logs operacionais apresentarão inúmeras mensagens de erro saslStart. Para otimizar conexões curtas do PHP em cenários de alta concorrência, o ApsaraDB for MongoDB aprimorou a reescrita de funções aleatórias nativas na camada de kernel, ajudando a reduzir a utilização da CPU na instância.
-
Índices Time-to-live (TTL) causam maior utilização de CPU no nó secundário em comparação ao primário. Nesse caso, ignore o alto consumo de CPU desse nó.
O MongoDB 3.2 e versões posteriores suportam replicação multithread. A concorrência de replay dos oplogs é definida pelo parâmetro replWriterThreadCount, cujo valor padrão é 16. Os nós secundários não lidam com escritas de service. Contudo, em certos cenários, a utilização da CPU de um nó secundário pode superar a do primário. Por exemplo, ao configurar exclusão automática baseada em TTL para uma coleção no nó primário, o sistema apaga dados em lotes usando o índice da coluna de tempo, o que é eficiente. Essa operação é convertida em diversas exclusões individuais enviadas ao nó secundário. Como o replay de oplogs no secundário é menos eficiente, a reprodução multithread pode elevar facilmente a utilização da CPU nesse nó.
As exclusões TTL podem remover milhares de documentos expirados por segundo. O aumento resultante na utilização da CPU e no I/O de disco é uma carga esperada. Faça o scale up da instância quando a carga de trabalho exigir mais capacidade, ou aguarde a conclusão da limpeza de dados fragmentados e então ative o balancer para rebalancear os dados.
Em um cluster com sharding, investigue mais a fundo se a utilização da CPU não diminuir e o desempenho de inserção não melhorar após a limpeza de documentos órfãos. No CloudDBA ou nas métricas de monitoramento, compare o dirty cache e a taxa de exclusão TTL de cada shard. Um dirty cache alto pode fazer com que threads da aplicação participem do flush de páginas sujas, e uma taxa de exclusão TTL anormalmente alta em um único shard indica uma carga de trabalho de exclusão desequilibrada.
Métodos de solução de problemas
Visualizar e encerrar sessões ativas
Se as sessões de uma instância em funcionamento normal dispararem repentinamente para 100%, a causa costuma ser uma mudança no lado da aplicação. Motivos frequentes incluem verificação excessiva de documentos, ordenação e agregação de dados, além de picos de tráfego de service. Siga os passos abaixo para solucionar o problema:
No console do ApsaraDB for MongoDB, acesse a página para visualizar as sessões ativas. Analise quaisquer consultas que estejam demorando mais do que o esperado e encerre a sessão ativa ou tome outras medidas corretivas.
Para visualizar e analisar detalhes das sessões ativas, execute o comando db.currentOp() fornecido pelo MongoDB. Se necessário, utilize o comando db.killOp() para encerrar ativamente consultas lentas não concluídas dentro do prazo esperado. Para mais informações, consulte db.currentOp() e db.killOp().
Registrar e visualizar logs
Quando a utilização da CPU aumentar de forma anormal, analise o log de consultas lentas ou o log de auditoria para identificar requisições problemáticas. Verifique palavras-chave como COLLSCAN e docsExamined para confirmar se um número excessivo de documentos está sendo verificado.
-
Logs de auditoria
No console do ApsaraDB for MongoDB, acesse a página para ativar e visualizar o log de auditoria. Para mais detalhes sobre como ativar e usar esse recurso, consulte Enable the audit log feature.
-
Logs de consultas lentas
ImportanteÉ possível visualizar apenas os logs de consultas lentas dos últimos sete dias.
Para instâncias adquiridas após 6 de junho de 2021, ative primeiro o recurso de log de auditoria e defina os tipos de operações auditadas para incluir admin e slow. Só então será possível visualizar o log de consultas lentas. Apenas as consultas lentas ocorridas após a ativação do log de auditoria serão registradas.
-
No console do ApsaraDB for MongoDB, acesse a página . Configure os parâmetros operationProfiling.mode (modo de consulta lenta) e operationProfiling.slowOpThresholdMs (limiar de consulta lenta) de acordo com as necessidades do seu negócio.
O MongoDB oferece três modos de profiling:
Profiling desativado, sem coleta de dados.
Profiling ativado para todas as requisições. Os dados de execução de todas as requisições são gravados na coleção system.profile.
Profiling ativado para consultas lentas. Consultas que excederem o limiar especificado são registradas na coleção system.profile.
Para mais informações sobre os parâmetros de profiling, consulte Database Profiler.
Na página , visualize os logs de consultas lentas.
Estratégias de otimização
Otimizar índices
A otimização de índices é a melhor solução para reduzir a quantidade de documentos que uma única consulta precisa verificar. Em sua arquitetura subjacente, o ApsaraDB for MongoDB utiliza um design de índices semelhante ao do MySQL, oferecendo categorias e recursos ainda mais ricos. Portanto, a maioria das estratégias de otimização de índices aplicáveis ao MySQL também se aplica ao ApsaraDB for MongoDB.
Para mais informações sobre como criar e usar índices, consulte Best practices for creating indexes in ApsaraDB for MongoDB ou os documentos oficiais abaixo:
Sobre índices compostos, veja Compound Indexes.
Para usar índices na ordenação de resultados de consultas, consulte Use Indexes to Sort Query Results.
Sobre hints, acesse Cursor Methods e cursor.hint().
Para equilibrar a seletividade de dados de um campo com a frequência de seleção, leia Create Queries that Ensure Selectivity.
Adicionar núcleos de CPU
Caso confirme que não há problemas nas consultas, a alta utilização da CPU decorre do grande volume de requisições de service e da alta concorrência. Adicione núcleos de CPU para resolver essa questão. Na maioria dos casos, utilize um dos métodos abaixo para adicionar núcleos:
Faça o scale up de uma única instância para suportar mais cargas de leitura e escrita.
Configure a separação de leitura/escrita no nível do replica set ou adicione instâncias somente leitura ao replica set.
Atualize a instância problemática para uma instância de cluster com sharding, permitindo scale-out linear.
Se a CPU dos nós de roteamento Mongos estiver esgotada, adicione nós Mongos e configure balanceamento de carga para eles. Para mais informações sobre balanceamento de carga de nós Mongos, consulte Load balancing.
Para obter mais detalhes sobre como alterar as configurações de uma instância do ApsaraDB for MongoDB, consulte Change the configuration of a standalone instance, Change replica set instance configurations e Change the configurations of a sharded cluster instance.
Controlar o número de coleções e a frequência de execução
Recomendamos adicionar índices primeiramente para otimizar varreduras completas de coleções. Se essa abordagem deixar de surtir efeito, controle o volume de dados das coleções e a frequência de execução no lado da aplicação.
Evitar conexões curtas frequentes
Sempre que possível, utilize conexões persistentes.
FAQ
Por que a utilização da CPU aumenta após uma atualização de versão do MongoDB?
Uma atualização de versão pode elevar a utilização da CPU quando parâmetros padrão mudam ou quando o plano de consulta é alterado. Siga os passos abaixo para identificar as operações afetadas e otimizá-las.
Execute
db.currentOp()nomongoshpara identificar requisições longas ou anormais. Se umopidanormal for retornado, executedb.killOp(opid)para encerrar essa operação.No console do ApsaraDB for MongoDB, acesse a página CloudDBA > Instance Sessions para analisar sessões ativas e encontrar requisições com tempo de execução inesperado.
Acesse a página Log Management > Slow log para identificar varreduras de coleção ou consultas que não utilizam índices. Otimize os índices com base nos resultados do log de consultas lentas.