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á.

# Consultas de longa duração
<a name="anti-pattern-long-running-queries"></a>

## Visão geral do
<a name="long-queries-overview"></a>

Long-running as consultas podem se transformar em problemas de desempenho em todo o cluster. Essas consultas podem interferir no processo de coleta de lixo do Amazon DocumentDB Multi-Version Concurrency Control (MVCC), levando ao acúmulo de documentos com versões antigas e à degradação do desempenho em todo o cluster. O Amazon DocumentDB implementa um tempo limite de 2 horas no servidor como um mecanismo de segurança para impedir que consultas descontroladas consumam recursos indefinidamente.

**O que são consultas de longa duração:**
+ Consultas que são executadas por longos períodos (normalmente > 30 minutos)
+ Cursores abertos que permanecem ativos por horas (o tempo limite de 2 horas não será aplicável se o cursor estiver ativo)

## Impacto no cluster
<a name="long-queries-impact"></a>

**Consultas de longa duração podem interferir no processo de coleta de lixo**
+ **Versões antigas se acumulam: o** coletor de lixo não pode recuperar versões antigas do documento
+ **Inchaço da coleção e do índice**: as entradas da coleção e do índice se acumulam com o tempo, o inchaço aumenta e isso pode resultar em mais custos de armazenamento.
+ **Pressão da CPU e da memória**: a pressão da CPU e da memória aumenta devido ao processamento ineficiente do maior número de versões de documentos antigos, entradas de índice e IDs de transações.

Consulta de longa duração → Bloqueia GC → Crescimento do armazenamento → Pressão da CPU e da memória → Mais consultas longas

## Monitore e detecte
<a name="long-queries-monitoring"></a>

**1. Para encontrar consultas de longa duração, use o comando CurrentOp.**

```
// To find a query running for more than 30 mins
db.adminCommand({
    aggregate: 1,
    pipeline: [
        {$currentOp: {}},
        {$match: 
            {$or: 
                [{secs_running: {$gt: 1800}},
                 {WaitState: {$exists: true}}]}}],
    cursor: {}
});
```

**2. Para encontrar cursores ativos por mais de 30 minutos**

```
// To find cursor which is running more than 30 mins
db.adminCommand({
    "currentOp": true,
    "active": true,
    "$all": true
}).inprog.filter(function(op) {
    return op.desc == "Cursor" && 
           op.secs_running > 1800 && 
           op.active == true;
}).sort((a, b) => b.microsecs_running - a.microsecs_running)
```

**3. Monitorando o progresso do coletor de lixo por meio de CloudWatch**

`LongestRunningGCProcess`— Duração em segundos do processo de coleta de lixo ativo mais longo. Atualiza a cada minuto e rastreia somente as operações ativas, excluindo os processos concluídos dentro da janela de um minuto.

`AvailableMVCCIds`-Um contador que mostra o número de operações de gravação restantes disponíveis antes de chegar a zero. Quando esse contador chega a zero, seu cluster entra no modo somente de leitura até que os IDs sejam recuperados e reciclados. O contador diminui a cada operação de gravação e aumenta à medida que a coleta de resíduos recicla IDs de MVCC antigos.

**nota**  
IDs de MVCC mais baixos e maior duração da coleta de lixo não são atribuídos exclusivamente a consultas de longa duração. Write-intensive cargas de trabalho em instâncias com recursos limitados também podem resultar na redução da disponibilidade do MVCC ID e em ciclos prolongados de coleta de lixo.

## Estratégias de remediação
<a name="long-queries-remediation"></a>
+ Implemente tempos limite de consulta no aplicativo
+ Não mantenha os cursores ativos por períodos mais longos
+ Otimize as consultas para obter um melhor desempenho.
+ Prefira o agrupamento em lotes de operações de gravação