Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

# Interrogazioni a lunga durata
<a name="anti-pattern-long-running-queries"></a>

## Panoramica di
<a name="long-queries-overview"></a>

Long-running le query possono causare problemi di prestazioni a livello di cluster. Queste query possono interferire con il processo di raccolta dei rifiuti Multi-Version Concurrency Control (MVCC) di Amazon DocumentDB, con conseguente accumulo di documenti con versioni precedenti e un peggioramento delle prestazioni in tutto il cluster. Amazon DocumentDB implementa un timeout lato server di 2 ore come meccanismo di sicurezza per impedire che le query inutilizzate consumino risorse a tempo indeterminato.

**Cosa sono le query a lunga durata:**
+ Query eseguite per periodi prolungati (in genere > 30 minuti)
+ Apri i cursori che rimangono attivi per ore (il timeout di 2 ore non è applicabile se il cursore è attivo)

## Impatto sul cluster
<a name="long-queries-impact"></a>

**Le interrogazioni di lunga durata possono interferire con il processo di raccolta dei rifiuti**
+ **Le versioni precedenti si accumulano**: Garbage collector non può recuperare le vecchie versioni dei documenti
+ **Incremento della raccolta e dell'indice: le voci relative alla** raccolta e all'indice si accumulano nel tempo, aumentano e ciò può comportare un aumento dei costi di archiviazione.
+ Pressione **della CPU e della memoria: la pressione** sulla CPU e sulla memoria aumenta a causa dell'elaborazione inefficiente di un maggior numero di vecchie versioni di documenti, voci di indice e ID di transazione.

Query a esecuzione prolungata → Blocchi GC → Storage Growth → Pressione della CPU e della memoria → Altre query lunghe

## Monitora e rileva
<a name="long-queries-monitoring"></a>

**1. Per trovare query a esecuzione prolungata, utilizzare il 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. Per trovare cursori attivi per più di 30 minuti**

```
// 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. Monitoraggio dei progressi di Garbage Collector tramite CloudWatch**

`LongestRunningGCProcess`— Durata in secondi del processo di raccolta dei rifiuti attivo più lungo. Si aggiorna ogni minuto e tiene traccia solo delle operazioni attive, esclusi i processi che vengono completati entro la finestra di un minuto.

`AvailableMVCCIds`-Un contatore che mostra il numero di operazioni di scrittura rimanenti disponibili prima di raggiungere lo zero. Quando questo contatore raggiunge lo zero, il cluster entra in modalità di sola lettura fino a quando gli ID non vengono recuperati e riciclati. Il contatore diminuisce a ogni operazione di scrittura e aumenta man mano che la Garbage Collection ricicla i vecchi ID MVCC.

**Nota**  
Gli ID MVCC inferiori e la durata estesa della Garbage Collection non sono attribuiti esclusivamente a query di lunga durata. Write-intensive i carichi di lavoro su istanze con risorse limitate possono inoltre comportare una riduzione della disponibilità degli ID MVCC e prolungare i cicli di raccolta dei rifiuti.

## Strategie di riparazione
<a name="long-queries-remediation"></a>
+ Implementa i timeout delle query nell'applicazione
+ Non mantenete attivi i cursori per periodi prolungati
+ Ottimizza le query per prestazioni migliori.
+ Preferisci il raggruppamento in batch delle operazioni di scrittura