A alta utilização de CPU em uma instância do ApsaraDB for MongoDB — que às vezes se aproxima de 100% — desacelera as operações de leitura e gravação e interrompe as atividades do negócio. Siga as etapas de diagnóstico abaixo para identificar e resolver a causa raiz.
Verificar operações em execução
Conecte-se à instância usando o mongo shell. Os procedimentos de conexão variam conforme a arquitetura da instância:
Execute db.currentOp() para listar todas as operações em execução na instância:
db.currentOp()Exemplo de saída:
{
"desc" : "conn632530",
"threadId" : "140298196924160",
"connectionId" : 632530,
"client" : "11.xxx.xxx.236:57052",
"active" : true,
"opid" : 1008837885,
"secs_running" : 0,
"microsecs_running" : NumberLong(70),
"op" : "update",
"ns" : "mygame.players",
"query" : {
"uid" : NumberLong(31577677)
},
"numYields" : 0,
"locks" : {
"Global" : "w",
"Database" : "w",
"Collection" : "w"
},
....
}Analise os campos a seguir para identificar operações problemáticas:
|
Campo |
Descrição |
Quando agir |
|
|
Cliente que enviou a solicitação |
Rastreie a solicitação até sua source |
|
|
ID exclusivo da operação |
Execute |
|
|
Tempo de execução da operação, em segundos |
Investigue operações com valores inesperadamente altos |
|
|
Tempo de execução da operação, em microssegundos |
Verifique operações com valores anormalmente elevados |
|
|
Namespace (coleção) em verificação |
Cruze essa informação com logs de consultas lentas para encontrar coleções com alta demanda |
|
|
Tipo de operação: |
— |
|
|
Informações de bloqueio da operação |
Consulte FAQ: Concurrency |
Para obter mais informações sobre db.currentOp(), consulte db.currentOp().
Picos de CPU frequentemente resultam de operações de O&M — como uma varredura completa de coleção — executadas simultaneamente à carga de trabalho regular. Se db.currentOp() exibir uma operação com um valor alto em secs_running não esperado, interrompa-a:
db.killOp(<opid>)Substitua <opid> pelo valor do campo opid na saída de db.currentOp(). Para mais detalhes, consulte db.killOp().
Analisar logs de consultas lentas
Caso a utilização de CPU aumente logo após o início da aplicação e permaneça elevada, mas db.currentOp() não mostre operações claramente problemáticas, a causa provável é um padrão de consultas lentas acumuladas ao longo do tempo.
Visualize os logs de consultas lentas no console do ApsaraDB for MongoDB. Para mais informações, consulte View slow query logs.
Exemplo de entrada de log de consulta lenta:
{
"atype": "slowOp",
"param": {
"op": "query",
"ns": "abbott_analysis.uaidScanInfo",
"query": {
"find": "uaidScanInfo",
"filter": {
"dateType": 2,
"companyCode": "GMP"
},
"ntoreturn": -1,
"sort": {
"scanDateTime": -1
}
},
"keysExamined": 0,
"docsExamined": 2181021,
"hasSortStage": true,
"cursorExhausted": true,
"numYield": 17059,
"locks": { ... },
"nreturned": 0,
"responseLength": 20,
"millis": 4878,
"planSummary": "COLLSCAN"
},
"result": "OK"
}Procure pelos seguintes padrões nos logs de consultas lentas:
Varreduras completas de coleção (COLLSCAN, docsExamined)
planSummary: COLLSCAN indica que a consulta percorreu toda a coleção sem usar um índice. O campo docsExamined mostra quantos documentos foram examinados — quanto maior esse número, mais CPU a consulta consumiu.
Crie um índice nos campos consultados para corrigir isso:
db.<collection>.createIndex({ <field>: 1 })Índices ineficientes (IXSCAN, keysExamined)
Quando uma consulta utiliza um índice, planSummary exibe IXSCAN. O campo keysExamined indica quantas chaves de índice foram verificadas. Quanto maior o valor, mais recursos de CPU a solicitação consome.
Exemplo de seletividade de índice
Considere uma coleção em que o campo x possui apenas dois valores possíveis (1 ou 2), enquanto y abrange uma faixa muito mais ampla (de 1 a 100000). Para a consulta { x: 1, y: 2 }:
{ x: 1, y: 1 }
{ x: 1, y: 2 }
...
{ x: 1, y: 100000 }
{ x: 2, y: 1 }
...|
Índice |
Seletividade |
Motivo |
|
|
Baixa |
Metade da coleção compartilha o mesmo valor de |
|
|
Baixa |
O campo principal |
|
|
Alta |
|
|
|
Alta |
O campo principal |
Indexe primeiro o campo de alta seletividade. Para mais informações, consulte Compound indexes.
O excesso de índices afeta o desempenho de gravação e atualização. Se sua aplicação envolve um grande volume de operações de escrita e utiliza índices, o desempenho pode ser comprometido. Audite e remova índices não utilizados caso o desempenho de gravação também esteja degradado.
Ordenação em memória (SORT, hasSortStage)
hasSortStage: true significa que a instância ordenou os resultados da consulta em memória porque nenhum índice pôde atender à ordem de classificação. Ordenações em memória para grandes conjuntos de resultados consomem muita CPU.
Se os logs de consultas lentas contiverem a palavra-chave SORT, crie um índice nos campos usados na cláusula de ordenação:
db.<collection>.createIndex({ <sort-field>: 1 })Outras operações com alto consumo de CPU
A criação de índices e pipelines de aggregation (que combinam travessia, filtragem, atualizações e ordenação) também podem causar alto uso de CPU. Aplique a mesma abordagem de diagnóstico: verifique docsExamined, keysExamined, hasSortStage e planSummary nos logs de consultas lentas.
Avaliar a capacidade do service
Se todas as consultas estiverem usando índices adequados e a utilização de CPU permanecer alta, a instância pode ter atingido seu limite de capacidade.
Revise os dados de monitoramento para entender seu padrão de uso de recursos. Para mais informações, consulte View monitoring data e Node monitoring (previously basic monitoring).
Teste seu banco de dados MongoDB para determinar se a instância atual oferece o desempenho e a capacidade de service necessários para sua carga de trabalho.
Se precisar atualizar a instância, consulte Change the configurations of an instance ou Change the number of nodes in a replica set instance.
Referência rápida
|
Comando |
Finalidade |
|
|
Listar todas as operações em execução na instância |
|
|
Interromper uma operação específica pelo seu ID de operação |
|
Visualizar logs de consultas lentas no console |
Identificar consultas lentas sem conectar-se à instância |