View a markdown version of this page

Consulta em execução lenta - Amazon DocumentDB
Identificação - Identifique o problemaInvestigue — Reúna informaçõesDiagnosticar — Encontre a causa raizResolver — Corrija o problema

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Consulta em execução lenta

Identificação - Identifique o problema

Uma consulta de execução lenta é aquela que excede o tempo de execução esperado para seus requisitos de negócios. A definição do que constitui uma consulta lenta varia entre diferentes cargas de trabalho. Você pode identificar consultas lentas por meio de registros do profiler ou Performance Insights.

  1. Ative o profiler se ainda não estiver ativado. Os registros do Profiler são gravados na Amazon CloudWatch sob o Log Group:/aws/docdb/<cluster-identifier>/profiler. Use o CloudWatch Logs Insights para consultá-los.

    Exemplo de consulta de análise de CloudWatch log para obter as 10 consultas mais lentas da coleção ecommerce.products:

    
filter ns="ecommerce.products" | sort millis desc | limit 10

  2. Use o Performance Insights para identificar consultas caras quase em tempo real. Ative o Performance Insights se ele ainda não estiver ativado.

    1. Abra o AWS console, navegue até Amazon Amazon DocumentDB, depois Performance Insights e selecione sua instância de cluster.

    2. Analise o cronograma de carregamento de banco de dados (AAS) e as principais consultas (por carga de banco de dados). Expanda um resumo de consulta para ver declarações secundárias literais.

    3. Capture as consultas que exigem análise.

    nota

    Nem todas as consultas no Performance Insights podem ser ineficientes ou lentas.

Investigue — Reúna informações

  1. O criador de perfil fornece o plano de execução da consulta e as principais métricas associadas a ele, incluindo millis, nreturned e planSummary (uso do índice):

    
{
    "op": "query",
    "ts": 1721374275673,
    "ns": "test.perf",
    "command": {
        "find": "perf",
        "filter": {
            "threadRunCount": 0
        },
        "$db": "test",
        "lsid": {
            "id": {
                "$binary": "oO2wEtpgQIK+y9KGByYnsw==",
                "$type": "4"
            }
        },
        "$readPreference": {
            "mode": "secondaryPreferred"
        }
    },
    "cursorExhausted": true,
    "nreturned": 0,
    "responseLength": 0,
    "protocol": "op_query",
    "millis": 137,
    "planSummary": "IXSCAN",
    "execStats": {
        "stage": "FETCH",
        "nReturned": "0",
        "executionTimeMillisEstimate": "100.346",
        "inputStage": {
            "stage": "IXSCAN",
            "nReturned": "0",
            "executionTimeMillisEstimate": "100.342",
            "indexName": "threadRunCount_1"
        }
    },
    "client": "172.31.6.165:43154",
    "appName": "ProdAppTester14",
    "user": "adminuser"
}

    Para encontrar as consultas do COLLSCAN:

    
filter planSummary="COLLSCAN" | sort millis desc | limit 20

  2. Use o Performance Insights para analisar tendências de execução de consultas, como esperas, carga e impacto nos recursos (por exemplo, IOPS ou CPU por consulta) em tempo real.

    Como o Performance Insights não fornece o plano de execução da consulta, capture a consulta e execute explain (“ExecutionStats”) na consulta em seu cluster Amazon DocumentDB:

    
db.ecommerce.products.find().explain("executionStats")

  3. Opcionalmente, correlacione as métricas do profiler com os dados do Performance Insights (por exemplo, combine muitos milhões de consultas no Profiler com as principais consultas no Performance Insights).

Diagnosticar — Encontre a causa raiz

Nesta etapa, diagnostique o plano de consulta para identificar possíveis otimizações. Use o seguinte fluxo - sintoma → causa provável:

  • Sintoma: Resumo do plano: “COLLSCAN”

    Causa: Índice ausente ou incorreto.

  • Sintoma: agregação lenta com $group/$sort

    Causa: o pipeline de agregação pode estar processando muitos dados na memória.

  • Sintoma: altas latências enquanto o Performance Insights mostra a carga de banco de dados agrupada por esperas de E/S, embora os índices sejam utilizados (PlanSummary: “IXSCAN”).

    Causa: consultas I/O vinculadas; índices ou conjuntos de trabalho excedem o cache de buffer disponível na instância.

  • Sintoma: PI mostra estados de espera da CPU, alto AAS devido a poucas consultas

    Causa: CPU-bound consultas (agregações complexas, $regex).

  • Sintoma: muitas consultas lentas, mas nenhuma mostra um plano caro. Resumo

    Causa: gargalo externo (rede, limitação, tarefas de manutenção, volume de consultas).

Resolver — Corrija o problema

Ao implementar correções, sempre valide com explain (“ExecutionStats”) e monitore a carga de banco de dados do Performance Insights.

  1. Resumo do plano: “COLLSCAN”

    • Crie um índice direcionado.

      Exemplo: Para consultas frequentes que filtram por {categoria, preço} e classificam por preço decrescente:

      
db.products.createIndex({ category: 1, price: -1 })

  2. agregação lenta com $group/$sort

    • Pressione $match e $project com antecedência para reduzir o fluxo de documentos para $group/$sort.

    • Limite o número de campos no início do pipeline:

      
db.products.explain("executionStats").aggregate([
  { $match: { category: "Electronics", price: { $gt: 0 } } },   // early filter
  { $project: { price: 1, category: 1 } },                     // reduce document size
  { $group: { _id: "$category", avgPrice: { $avg: "$price" } } }
])

  3. altas latências, enquanto o Performance Insights mostra a carga de banco de dados agrupada por esperas de E/S

    • Valide se BufferCacheHitRatio está baixo ou se os ReadiOps na instância estão altos. Aumente a memória da instância (atualize a classe da instância, por exemplo, r6g.large → r6g.xlarge) ou use a classe de instância NVMe.

    • Reduza a pegada do índice.

    • Adicione réplicas de leitura para descarregar o tráfego de leitura (use a configuração ReadPreference para redirecionar o tráfego nas réplicas se a consulta for tolerante com uma eventual consistência).

  4. PI mostra estados de espera da CPU, alto AAS devido a poucas consultas

    • Substitua o caro $regex por pesquisas de prefixo indexado ou índice $text.

    • Gravações em lote (inserção) para reduzir a amplificação de gravação.

nota

Sempre teste suas alterações em um ambiente inferior (sem produção) antes de promover essas alterações para a Produção.