Resolve high memory usage issues - ApsaraDB for MongoDB: Central de Documentação do Alibaba Cloud

Informações gerais

Quando um processo do ApsaraDB for MongoDB é iniciado, ele carrega arquivos binários e bibliotecas de sistema dependentes na memória e gerencie a alocação e a liberação de memória para tarefas como gerenciamento de conexões de clientes, processamento de requisições e o mecanismo de armazenamento. Por padrão, o ApsaraDB for MongoDB usa o tcmalloc do Google como alocador de memória. O consumo de memória ocorre principalmente no mecanismo de armazenamento WiredTiger e no gerenciamento de conexões de clientes e processamento de requisições.

Verificar o uso de memória

Analise os gráficos de monitoramento

Visualize o uso de memória do ApsaraDB for MongoDB na página Monitoring Information do console do ApsaraDB for MongoDB. A composição de nós das instâncias do ApsaraDB for MongoDB varia conforme a arquitetura da instância. Selecione um nó para visualize seu uso de memória.
- Arquitetura de conjunto de réplicas: inclui um nó primário, um ou mais nós secundários, um nó oculto e, opcionalmente, um ou mais nós somente leitura.
- Arquitetura de cluster sharded: o uso de memória de cada shard é semelhante ao de um conjunto de réplicas. O Config Server armazena metadados de configuração. O uso de memória de um nó de roteamento mongos está relacionado ao tamanho dos conjuntos de resultados de agregação, ao número de conexões e ao tamanho dos metadados.

Use a linha de comando

Conecte-se à instância pelo mongo shell e execute o comando db.serverStatus().mem para visualize e analisar o uso de memória. O código a seguir apresenta um exemplo de saída:

{ "bits" : 64, "resident" : 13116, "virtual" : 20706, "supported" : true }
// resident indicates the physical memory used by the mongod process, in MB.
// virtual indicates the virtual memory used by the mongod process, in MB.

Nota

Referência do comando serverStatus.

Causas comuns

Memória do mecanismo de armazenamento

A maior parte da memória de uma instância do ApsaraDB for MongoDB é usada pelo cache do mecanismo de armazenamento. Por compatibilidade e segurança, o ApsaraDB for MongoDB defina o CacheSize do WiredTiger em aproximadamente 60% da memória total alocada para a instância. Consulte as especificações do produto.

Quando o uso do cache do mecanismo de armazenamento atinge 95% do CacheSize configurado, a instância opera sob alta carga e as threads que processam requisições de usuários passam a remover páginas limpas. Se os dados sujos no cache ultrapassarem 20% do CacheSize, as threads de usuário também removerão páginas sujas. Durante esse processo, os usuários podem perceber bloqueios perceptíveis nas requisições. Consulte as descrições dos parâmetros de eviction.

Verifique o uso de memória do mecanismo com os seguintes métodos:

Verifique o uso de memória do mecanismo de armazenamento WiredTiger

No mongo shell, execute o comando db.serverStatus().wiredTiger.cache. O campo bytes currently in the cache na saída indica a quantidade de memória usada pelo cache. O código a seguir apresenta um exemplo de saída:
```
{
   ......
   "bytes belonging to page images in the cache":6511653424,
   "bytes belonging to the cache overflow table in the cache":65289,
   "bytes currently in the cache":8563140208,
   "bytes dirty in the cache cumulative":NumberLong("369249096605399"),
   ......
}
```

Verifique a proporção de dados sujos no cache do mecanismo WiredTiger
- A página Real-Time Monitoring Data no console do Database Autonomy Service (DAS) exibe a proporção de dados sujos no cache do mecanismo WiredTiger em tempo real.
- Use a ferramenta mongostat incluída no ApsaraDB for MongoDB para verificar a proporção atual de dados sujos no cache do mecanismo WiredTiger. Consulte a referência do mongostat.

Memória de conexões e requisições

Um número elevado de conexões consome memória significativa pelos seguintes motivos:

Overhead da pilha de threads: cada conexão tem uma thread de backend correspondente para processar suas requisições. Cada thread pode consumir até 1 MB de espaço de pilha, embora o uso típico fique na faixa de dezenas a centenas de kilobytes.
Buffers de kernel de conexões TCP: no nível do kernel, cada conexão TCP tem buffers de leitura e escrita, determinados por parâmetros de kernel TCP como tcp_rmem e tcp_wmem. Não é necessário gerencie essa memória diretamente. No entanto, mais conexões simultâneas e um buffer de socket padrão maior aumentam o consumo de memória TCP.
Gerenciamento de memória do tcmalloc: cada requisição aloca buffers temporários para tratamento de pacotes e ordenação. Após a conclusão, esses buffers retornam ao cache interno do tcmalloc em vez de serem devolvidos imediatamente ao sistema operacional. O tcmalloc libera gradualmente a memória em cache, mas a memória não liberada pode se acumular até dezenas de gigabytes.

Métodos de investigação:

Verifique o uso de conexões
- Na página Monitoring Information do console do ApsaraDB for MongoDB, visualize o uso de conexões da sua instância do ApsaraDB for MongoDB.
- No mongo shell, consulte o número de conexões.
Verifique a quantidade de memória retida pelo tcmalloc
Execute o comando db.serverStatus().tcmalloc para verificar a quantidade de memória que o tcmalloc não devolveu ao sistema operacional. O tamanho do cache do tcmalloc pode ser calculado pela seguinte fórmula: tcmalloc cache = pageheap_free_bytes + total_free_byte. O código a seguir apresenta um exemplo de saída:
```
{
   ......
   "tcmalloc":{
           "pageheap_free_bytes":NumberLong("3048677376"),
           "pageheap_unmapped_bytes":NumberLong("544994184"),
           "current_total_thread_cache_bytes":95717224,
           "total_free_byte":NumberLong(1318185960),
           ......
   }
}
```
Nota
Referência do alocador de memória tcmalloc.

Memória de metadados

Um grande número de bancos de dados, coleções e índices em uma instância do ApsaraDB for MongoDB consome memória significativa devido aos metadados associados. Versões anteriores do ApsaraDB for MongoDB podem apresentar os seguintes problemas:

Em versões do ApsaraDB for MongoDB anteriores à 4,0, um backup lógico completo pode abrir um grande número de descritores de arquivo. Se esses descritores não forem devolvidos ao sistema operacional prontamente, o uso de memória pode aumentar rapidamente.
No ApsaraDB for MongoDB 4,0 e versões anteriores, a exclusão de um grande número de coleções pode não remover corretamente os descritores de arquivo correspondentes, causando vazamento de memória.

Memória de criação de índices

Durante gravações normais de dados, um nó secundário mantém um buffer de até aproximadamente 256 MB para aplicação de oplog. No entanto, a replicação de operações de criação de índices em um nó secundário pode consumir mais memória.

Em versões do ApsaraDB for MongoDB anteriores à 4,2, a criação de índices suporta a opção background. Ao especifique {background:true}, o índice é criado em segundo plano. A replicação dessa operação é serial e pode consumir até 500 MB de memória.
No ApsaraDB for MongoDB 4,2 e versões posteriores, a opção background foi descontinuada. Os nós secundários podem replicar operações de criação de índices em paralelo, o que consome mais memória. A criação simultânea de múltiplos índices pode causar um erro de falta de memória (OOM).

Nota

Documentação do MongoDB: Index Build Impact on Database Performance e Index Build Process.

Uso de memória do cache de planos

Em alguns cenários, uma única consulta pode ter um grande número de planos de execução candidatos, fazendo com que o cache de planos consuma uma quantidade significativa de memória.

Verifique o uso de memória do cache de planos: no ApsaraDB for MongoDB 4,0 e versões posteriores, execute o comando db.serverStatus().metrics.query.planCacheTotalSizeEstimateBytes para verificar o uso de memória.

Nota

Se a sua instância execute o ApsaraDB for MongoDB 4,0, mas o comando não retorna o campo planCacheTotalSizeEstimateBytes, a versão secundária da instância está desatualizada. Recomendamos atualize a versão secundária da instância.
Relacionado: Secondary node memory arise while balancer doing work.

Estratégias de otimização

O objetivo da otimização de memória é equilibrar a utilização de recursos e o desempenho — não minimizar o uso a qualquer custo.

O ApsaraDB for MongoDB defina o CacheSize, que não pode ser modificado. Aplique as seguintes estratégias para otimizar o uso de memória:

Controle as conexões simultâneas. Por padrão, o driver do MongoDB estabelece um pool de 100 conexões. Se muitos clientes se conectarem, reduza o tamanho do pool por cliente. Mantenha o total de conexões persistentes abaixo de 1.000 para evitar consumo excessivo de memória e overhead de troca de contexto.
Reduza o overhead de memória por requisição criando índices para evitar varreduras completas de coleções e ordenações em memória.
Se o uso de memória permanecer alto após a otimização de consultas e conexões, atualize a especificação de memória da instância para evitar erros OOM e degradação de desempenho causada por eviction excessivo de cache.
Acelere a liberação de memória pelo tcmalloc. Se o uso de memória da instância de banco de dados ultrapassar 80%, ajuste os parâmetros relacionados ao tcmalloc na página Parameter Settings no console.
1. Ative o parâmetro tcmallocAggressiveMemoryDecommit. Essa configuração resolve efetivamente problemas de retenção de memória.
2. Se o problema persistir, aumente gradualmente o valor de tcmallocReleaseRate (por exemplo, de 1 para 3, depois para 5).
Importante
- Faça os ajustes durante períodos de baixo tráfego. Esses parâmetros podem degradar o desempenho do banco de dados. Reverta imediatamente caso seu negócio seja impactado.
- Monitore o uso de CPU, o tempo de resposta (RT) e os opCounters antes e após o ajuste para avaliar o impacto.
Otimize a quantidade de bancos de dados e coleções removendo coleções e índices desnecessários, consolidando tabelas, dividindo a instância ou migrando para um cluster sharded. Consulte Desempenho da instância lento ou anormal devido a um número excessivo de bancos de dados e tabelas.

Nota

Se você encontrar outros cenários que possam envolver o ApsaraDB for MongoDB ao utilizá-lo, entre em contato com o suporte técnico da Alibaba Cloud.

Referências

Parâmetros de eviction

Parâmetro	Padrão	Descrição
eviction_target	80%	Quando o uso do cache ultrapassa o eviction_target, as threads de eviction em segundo plano iniciam a remoção de páginas limpas.
eviction_trigger	95%	Quando o uso do cache ultrapassa o eviction_trigger, as threads de usuário também passam a remover páginas limpas.
eviction_dirty_target	5%	Quando a proporção de dados sujos no cache ultrapassa o eviction_dirty_target, as threads de eviction em segundo plano iniciam a remoção de páginas sujas.
eviction_dirty_trigger	20%	Quando a proporção de dados sujos no cache ultrapassa o eviction_dirty_trigger, as threads de usuário também passam a remover páginas sujas.
eviction_updates_target	2,5%	Quando a proporção de atualize no cache ultrapassa o eviction_updates_target, as threads de eviction em segundo plano iniciam a remoção de fragmentos de memória relacionados a objetos pequenos.
eviction_updates_trigger	10%	Quando a proporção de atualize no cache ultrapassa o eviction_updates_trigger, as threads de usuário também passam a remover fragmentos de memória relacionados a objetos pequenos.

Perguntas frequentes

P: Como aumentar o limite de memória para operações de agregação no MongoDB?

R: O ApsaraDB for MongoDB não permite aumentar diretamente o limite de memória para operações de agregação. Cada estágio de um pipeline de agregação do MongoDB tem um limite de 100 MB de memória. Se um estágio ultrapassar esse limite, o sistema retorna um erro. Para resolver o problema, especifique explicitamente a opção {allowDiskUse:true} no seu pipeline de agregação. O MongoDB 6.0 e versões posteriores suportam o parâmetro padrão global allowDiskUseByDefault. Quando uma operação de agregação exige memória excessiva, o MongoDB usa automaticamente espaço temporário em disco para evitar alto consumo de memória. Para outras estratégias de redução do uso de memória, consulte as estratégias de otimização.