ApsaraDB for MongoDB:Solucionar problemas de alta utilização de CPU em uma instância

Excesso de documentos verificados

O ApsaraDB for MongoDB utiliza multithreading. Quando uma única consulta verifica um grande número de documentos, sua thread retém recursos de CPU por mais tempo. Em cenários de alta concorrência, esse efeito se acumula e eleva a utilização geral de CPU. A carga total de CPU em uma instância correlaciona-se diretamente com o número total de documentos verificados em todas as consultas.

Dois padrões causam verificação excessiva de documentos:

Varreduras completas de coleção (COLLSCAN)

Um COLLSCAN no log de consultas lentas ou na coleção system.profile indica que a consulta leu todos os documentos de uma coleção. A coleção system.profile só é criada quando você ativa o profiling do banco de dados. Consulte Explain Results e Cursor Methods para saber como interpretar planos de execução de consultas.

Uso ineficiente de índices (docsExamined alto)

Quando o valor de docsExamined ultrapassa 1.000 em uma consulta executada frequentemente, essa consulta requer atenção. Causas comuns incluem:

• Múltiplas condições de filtro sem um índice composto ou sem respeitar a regra de prefixo do índice.

• Consultas complexas ou pipelines de agregação pesados que impedem o uso eficaz de índices.

• Um campo com distribuição de dados assimétrica (baixa seletividade) utilizado como filtro de consulta.

Alta concorrência

Se o número de solicitações simultâneas for genuinamente alto e não houver problemas nas consultas, será necessária capacidade adicional de CPU. Consulte Adicionar capacidade de CPU.

Outras causas

Tempestades de conexões de curta duração

Em versões posteriores ao MongoDB 3.X, o mecanismo de autenticação padrão é o SCRAM-SHA-1, que exige computação intensiva de hash por conexão. Quando muitas conexões de curta duração são estabelecidas simultaneamente, a sobrecarga de hash se multiplica e pode exaurir todos os recursos de CPU. Nesse cenário, os logs operacionais contêm muitas mensagens de erro saslStart. O ApsaraDB for MongoDB reduz essa sobrecarga na camada de kernel otimizando suas funções aleatórias integradas.

Reprodução de oplog de índice TTL em nós secundários

Ao usar índices time-to-live (TTL) para expirar dados, o MongoDB transforma as exclusões resultantes em múltiplas entradas de oplog. Os nós secundários reproduzem esses oplogs usando replicação multithread (controlada pelo parâmetro replWriterThreadCount, cujo valor padrão é 16 no MongoDB 3.2 e posteriores). Nós secundários não lidam com cargas de trabalho de escrita críticas para o negócio. No entanto, a reprodução de oplog é menos eficiente que a escrita original, portanto a CPU de um nó secundário pode ficar mais alta que a do nó primário. Nesse caso, recomendamos ignorar a alta utilização de CPU desse nó.

Interromper sessões ativas

Se a utilização de CPU estiver próxima de 100%, encerre as sessões que causam o pico antes de investigar a causa raiz.

Opção 1 — Console do ApsaraDB for MongoDB (recomendado)

1. No console do ApsaraDB for MongoDB, clique em ID da instância.

2. No painel de navegação à esquerda, escolha CloudDBA > Sessions.

3. Revise as sessões ativas, identifique operações em execução há mais tempo que o esperado e encerre-as.

A página Sessions permite visualizar e encerrar operações na mesma interface, sem necessidade de acesso ao shell. Esta é a opção mais rápida durante um pico de CPU.

Opção 2 — Shell do MongoDB

Execute db.currentOp() para listar as operações ativas e, em seguida, execute db.killOp() para encerrar uma operação específica. Para detalhes de sintaxe, consulte db.currentOp() e db.killOp().

Analisar logs para encontrar a causa raiz

Após interromper o pico imediato, identifique as consultas que o provocaram.

Audit logs

No console do ApsaraDB for MongoDB, escolha Data Security > Audit Logs para ativar o log de auditoria. Para instruções de configuração, consulte Ativar o recurso de log de auditoria.

Slow query logs

1. No console, escolha Parameters > Parameter List e configure os seguintes parâmetros: Consultas que excedem o limiar são registradas na coleção system.profile. Para detalhes dos parâmetros, consulte Database Profiler.

   Parâmetro	Descrição
   operationProfiling.mode	Defina o nível de profiling: desativado (nenhum dado coletado), todas as solicitações (dados registrados no system.profile) ou apenas consultas lentas (consultas que excedem o limiar registradas no system.profile)
   operationProfiling.slowOpThresholdMs	Defina o limiar em milissegundos acima do qual uma consulta é classificada como lenta

2. Escolha Logs > Slow Query Logs para visualizar os logs.

Nos logs, procure por:

• COLLSCAN — indica uma varredura completa da coleção.

• Valores de docsExamined muito superiores ao esperado — indicam baixa eficiência de índice.

Otimizar índices

A otimização de índices é a forma mais eficaz de reduzir o número de documentos verificados por consulta. Comece pelas consultas que apresentam COLLSCAN ou valores altos de docsExamined.

Recursos para otimização de índices:

• Melhores práticas para criação de índices no ApsaraDB for MongoDB

• Compound Indexes — para consultas com múltiplas condições de filtro

• Use Indexes to Sort Query Results

• cursor.hint() — para forçar um índice específico

• Create Queries that Ensure Selectivity — para campos com distribuição de dados assimétrica

Se apenas a indexação não resolver, limite o volume de dados nas coleções afetadas ou reduza a frequência da varredura completa da coleção.

Adicionar capacidade de CPU

Se as consultas já estiverem bem otimizadas e a CPU estiver alta devido a um volume real de tráfego, escale a instância. Abordagens comuns incluem:

• Escalar verticalmente a instância para obter mais margem de leitura e escrita.

• Ativar a divisão de leitura/escrita ou adicionar nós somente leitura a uma instância de conjunto de réplicas para distribuir a carga de leitura.

• Atualizar para uma instância de cluster fragmentado para escalonamento horizontal linear em múltiplos shards.

• Adicionar nós mongos se a CPU estiver exaurida na camada mongos e configurar o balanceamento de carga entre eles. Para detalhes, consulte a seção Balancer na introdução ao cluster fragmentado.

Para obter os passos necessários para alterar as configurações da instância, consulte:

• Alterar as configurações de uma instância autônoma

• Alterar as configurações de uma instância de conjunto de réplicas

• Alterar as configurações de uma instância de cluster fragmentado

Usar conexões persistentes

Conexões de curta duração acionam a autenticação SCRAM-SHA-1 a cada nova conexão, o que consome muita CPU em escala. Utilize um pool de conexões com conexões persistentes para eliminar a sobrecarga de autenticação por conexão.