Solução de problemas de desempenho para Databases for MongoDB

Use este guia para ajudá-lo a identificar e resolver problemas de desempenho em sua implantação Databases for MongoDB executada em IBM Cloud e alimentada por MongoDB.

Você também pode encontrar mais informações sobre como resolver problemas de desempenho da seguinte forma:

Se os seus aplicativos estiverem apresentando respostas lentas, tempos limite ou desempenho inconsistente do banco de dados, considere as etapas e informações a seguir.

Sintomas de problemas de desempenho

Você pode observar alguns dos seguintes sintomas que indicam problemas de desempenho:

Aumento da latência do aplicativo
Entradas de registro de consulta lentas
Alta utilização da CPU ou da memória
Aumento da latência do disco
Atraso da replicação
Tempos limite de conexão

Conclua as etapas a seguir para determinar a causa dos problemas:

Etapa 1: Verifique a utilização dos recursos

Faça login no console IBM Cloud e navegue até a implantação MongoDB.
Analise a seção Monitoramento para saber mais:
- Utilização da CPU
- Uso de memória
- IOPS e latência do disco
- Conexões ativas

O que procurar:

CPU consistentemente acima de 75%
Memória consistentemente acima de 80%
A latência do disco aumenta com o tempo
Conexões que se aproximam dos limites do plano

Ações recomendadas:

Aumente o armazenamento ou o IOPS se a latência do disco for alta.
Analise os picos de carga de trabalho em seu aplicativo.

Se o uso de recursos permanecer elevado por períodos prolongados, recomenda-se o escalonamento.

Etapa 2: Identificar consultas lentas

As consultas lentas são uma das causas mais comuns de desempenho degradado.

Ativar a criação de perfil:

db.setProfilingLevel(1, { slowms: 100 })

Analise as operações lentas recentes:

db.system.profile.find().sort({ ts: -1 }).limit(20)

Analisar a execução da consulta:

db.collection.find({ ... }).explain("executionStats")

O que procurar:

COLLSCAN (varredura de coleção em vez de uso de índice)
Alta totalDocsExamined em comparação com nReturned

Ações recomendadas:

Criar índices apropriados.
Use índices compostos para consultas de vários campos.
Garanta que os pipelines de agregação comecem com $match.
Evite a paginação skip() grande.

Etapa 3: Revisar o uso da conexão

Conexões altas ou mal gerenciadas podem afetar o desempenho.

Verifique as estatísticas de conexão:

db.serverStatus().connections

Ações recomendadas:

Use o pooling de conexões em seu aplicativo.
Evite abrir uma nova conexão para cada solicitação.
Feche os cursores não utilizados.

Os limites de conexão são determinados pelo seu plano de implantação.

Etapa 4: Verificar a integridade da replicação

O atraso na replicação pode afetar o desempenho da leitura e a atualização dos dados.

Verificar o status da replicação:

rs.printSecondaryReplicationInfo()

Causas comuns de atraso:

Alta taxa de transferência de gravação
Gargalos de disco
Latência de rede

Ações recomendadas:

Dimensionar o desempenho do armazenamento.
Revisar as configurações de preocupação de gravação.
Dimensione para um plano superior se o atraso for persistente.

Etapa 5: considerações sobre o cluster fragmentado (se aplicável)

Talvez você precise de sharding nas seguintes situações:

O conjunto de trabalho é maior que a RAM
IOPS de nó único atingido no máximo mesmo após o dimensionamento
É necessário o escalonamento de gravação horizontal
As coleções excedem 1-2 TB

Para obter mais informações, consulte ajuste de desempenho e sharding.

Se sua implantação usar sharding, execute:

sh.status()

Verifique se há:

Distribuição desigual de pedaços
Pedaços gigantes
Tráfego concentrado em um único fragmento

Ações recomendadas:

Revisar a seleção da chave de fragmento.
Evite aumentar monotonicamente as chaves de fragmento.
Considere as chaves de fragmento com hash.

A seleção incorreta da chave de fragmento pode afetar significativamente o desempenho em escala.

Etapa 6: Após grandes exclusões de dados

A exclusão de uma porcentagem significativa de dados não reduz imediatamente o uso do disco no nível do sistema operacional.

Possíveis impactos:

Fragmentação interna
Alta utilização de disco
Desempenho reduzido

Ações recomendadas:

Planeje cuidadosamente as operações de compactação.
Considere o dump and restore para fragmentação grave.
Mantenha a utilização do disco abaixo de 80-85%.

Programe adequadamente as atividades de manutenção.

Etapa 7: Verifique se há contenção de bloqueio

A contenção de bloqueios pode afetar gravemente as operações simultâneas e a taxa de transferência geral.

Verifique as estatísticas globais de bloqueio:
```
db.serverStatus().locks
```

Verifique se há bloqueios nas operações atuais:

db.currentOp({
  $or: [
    { waitingForLock: true },
    { "locks.Global": "w" }
  ]
})

Analisar o tempo de espera do bloqueio:
```
db.serverStatus().globalLock
```

O que procurar:

Valores altos currentQueue (leitores ou escritores).
Operações com waitingForLock: true.
Operações de longa duração que mantêm bloqueios.
Construções de índices que bloqueiam operações.

Causas comuns:

Consultas de longa duração sem índices adequados.
Grandes operações de gravação.
O índice se baseia em grandes coleções.
Comandos administrativos (compact, repairDatabase ).

Ações recomendadas:

Encerre operações de longa duração, se necessário:
```
db.killOp(opid)
```

Criar índices em segundo plano:

db.collection.createIndex({ field: 1 }, { background: true })

Divida as operações grandes em lotes menores.
Programe as operações de manutenção durante os períodos de pouco tráfego.
Use a preocupação de leitura e a preocupação de escrita adequadamente.

Etapa 8: Analisar os padrões de carga de trabalho

Compreender os padrões de sua carga de trabalho ajuda a identificar oportunidades de otimização.

Verifique os contadores de operação:
```
db.serverStatus().opcounters
```
Analisar as operações ao longo do tempo:
```
db.serverStatus().opcountersRepl
```
Identificar coleções quentes:
```
db.adminCommand({ top: 1 })
```

Verifique a taxa de leitura em comparação com a taxa de gravação:

var stats = db.serverStatus().opcounters;
print("Read ratio: " + (stats.query + stats.getmore) / (stats.query + stats.getmore + stats.insert + stats.update + stats.delete));

O que procurar:

Operações desproporcionais em coleções específicas
Altas taxas de leitura para gravação ou gravação para leitura
Picos repentinos na contagem de operações
Padrões baseados no tempo (horários de pico)

Ações recomendadas:

Otimize primeiro as coleções acessadas com frequência.
Considere réplicas de leitura para cargas de trabalho de leitura intensa.
Use as preferências de leitura apropriadas.
Implemente o armazenamento em cache para dados lidos com frequência.
Revisar a estratégia de indexação para coleções importantes.
Considere a fragmentação para coleções que exigem muita gravação.

Etapa 9: Investigar a pressão da memória e a eficiência do cache

MongoDB's WiredTiger o mecanismo de armazenamento depende muito da eficiência do cache.

Verifique as estatísticas de cache do site WiredTiger:
```
db.serverStatus().wiredTiger.cache
```

Analise as principais métricas:

var cache = db.serverStatus().wiredTiger.cache;
print("Cache size: " + cache["bytes currently in the cache"]);
print("Max cache size: " + cache["maximum bytes configured"]);
print("Pages read into cache: " + cache["pages read into cache"]);
print("Pages written from cache: " + cache["pages written from cache"]);
print("Cache hit ratio: " + (1 - cache["pages read into cache"] / (cache["pages read into cache"] + cache["pages requested from the cache"])));

Verifique se há pressão de despejo:

db.serverStatus().wiredTiger.cache["pages evicted by application threads"]

O que procurar:

Taxa de acerto do cache abaixo de 95%
Altas taxas de despejo
Tamanho do cache consistentemente no máximo
Threads de aplicativos que executam despejos

Estimar o tamanho do conjunto de trabalho:

db.serverStatus().wiredTiger.cache["tracked dirty bytes in the cache"]

Ações recomendadas:

Dimensione para um plano com mais memória se o cache estiver constantemente cheio.
Revisar e otimizar os índices (remover índices não utilizados).
Limitar o tamanho do conjunto de resultados nas consultas.
Use projeções para reduzir o tamanho do documento.
Considere arquivar dados antigos.
Monitore as tendências de tamanho do conjunto de trabalho.

Práticas recomendadas de alocação de memória

O cache do WiredTiger deve ser 50% da RAM disponível (padrão).
Deixe memória suficiente para outros processos.
Monitore o uso de swap, que deve ser mínimo.

Etapa 10: Revisar as configurações de preferência de gravação e leitura

As configurações de preferência de gravação e leitura afetam significativamente o desempenho e a consistência.

Verifique a preocupação atual com a gravação:
```
db.getWriteConcern()
```
Verifique a configuração do conjunto de réplicas:
```
rs.conf()
```

Escreva as opções de preocupação:

Opções de preocupação de gravação
Preocupação com a escrita	Durabilidade	Desempenho	Caso de uso
`w: 1`	Baixo	Alta	Dados não críticos, alta taxa de transferência
`w: "majority"`	Alta	Médio	Abordagem padrão e equilibrada
`w: <number>`	Médio-Alto	Médio-Baixo	Contagem específica de réplicas
`j: true`	Mais alta	Mais baixa	Dados críticos que exigem sincronização de diário

Opções de preferência de leitura:

Opções de preferência de leitura
Preferência de leitura	Consistência	Desempenho	Caso de uso
`primary`	Mais alta	Médio	Padrão, consistência forte
`primaryPreferred`	Alta	Médio-Alto	Retorno ao secundário
`secondary`	Eventual	Alta	Análises, relatórios
`secondaryPreferred`	Eventual	Alta	Escala de leitura
`nearest`	Eventual	Mais alta	Menor latência

Verifique a preferência de leitura em seu aplicativo:

// Example in Node.js driver
db.collection('users').find({}).readPreference('secondary')

O que procurar:

Preocupações de gravação excessivamente rígidas para dados não críticos
Usando a preferência de leitura primary quando a consistência eventual é aceitável
Não aproveitar os secundários para cargas de trabalho de leitura intensa

Ações recomendadas:

Use w: 1 para gravações de alto rendimento e não críticas.
Use w: "majority" para dados importantes (padrão).
Use secondary ou secondaryPreferred para consultas de análise.
Considere o site nearest para aplicativos distribuídos geograficamente.
Equilibrar os requisitos de consistência com as necessidades de desempenho.
Teste diferentes configurações sob carga.

Etapa 11: Monitore o impacto do backup e da manutenção

As operações de backup e as tarefas de manutenção podem afetar temporariamente o desempenho.

IBM Cloud programação de backup

Databases for MongoDB faz automaticamente um backup. Verifique sua programação de backup no console IBM Cloud em Backups.

Verifique se há operações de backup em andamento:

db.currentOp({
  $or: [
    { op: "command", "command.backup": { $exists: true } },
    { desc: /^conn/ }
  ]
})

O que procurar:

Degradação do desempenho durante as janelas de backup
Aumento da E/S do disco durante os backups
Atraso na replicação durante os backups

Ações recomendadas:

Monitore as métricas de desempenho durante os períodos de backup.
Considere o dimensionamento se os backups afetarem o desempenho de forma consistente.
Revisar as políticas de retenção de backup.
Planeje o aumento do uso de recursos durante as operações de restauração.

Práticas recomendadas de operação de manutenção

Programe a criação de índices durante os períodos de pouco tráfego.
Use compilações de índices em segundo plano sempre que possível.
Monitore o atraso da replicação durante a manutenção.
Teste primeiro as operações de manutenção em não-produção.
Coordenar com as janelas de manutenção do site IBM Cloud.