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à.
# Risoluzione dei problemi di Amazon DocumentDB
Le seguenti sezioni forniscono informazioni su come risolvere i problemi che potresti incontrare durante l'utilizzo di Amazon DocumentDB (con compatibilità con MongoDB).
**Topics**
+ [Problemi di connessione](troubleshooting.connecting.md)
+ [Indici](troubleshooting.index-creation.md)
+ [Prestazioni e utilizzo delle risorse](user_diagnostics.md)
+ [Raccolta dei rifiuti](garbage-collection.md)
# Risoluzione dei problemi di connessione
Hai problemi di connessione? Ecco alcuni scenari comuni e come risolverli.
**Argomenti**
+ [Impossibile connettersi a un endpoint Amazon DocumentDB](#troubleshooting-connecting)
+ [Test di una connessione a un'istanza Amazon DocumentDB](#troubleshooting.testing-connection)
+ [Connessione a un endpoint non valido](#troubleshooting.invalid-endpoint)
+ [Configurazione del driver che influisce sul numero di connessioni](#troubleshooting.driver.config)
## Impossibile connettersi a un endpoint Amazon DocumentDB
Quando tenti di connetterti ad Amazon DocumentDB, il seguente è uno dei messaggi di errore più comuni che potresti ricevere.
```
connecting to: mongodb://docdb-2018-11-08-21-47-27.cluster-ccuszbx3pn5e.us-east-
1.docdb.amazonaws.com:27017/
2018-11-14T14:33:46.451-0800 W NETWORK [thread1] Failed to connect to
172.31.91.193:27017 after 5000ms milliseconds, giving up.
2018-11-14T14:33:46.452-0800 E QUERY [thread1] Error: couldn't connect to server
docdb-2018-11-08-21-47-27.cluster-ccuszbx3pn5e.us-east-1.docdb.amazonaws.com:27017,
connection attempt failed :
connect@src/mongo/shell/mongo.js:237:13
@(connect):1:6
exception: connect failed
```
Ciò che questo messaggio di errore in genere significa è che il tuo client (la shell mongo in questo esempio) non può accedere all'endpoint Amazon DocumentDB. Questo potrebbe accadere per vari motivi:
**Topics**
+ [Connessione da endpoint pubblici](#troubleshooting.cannot-connect.public-endpoints)
+ [Connessioni interregionali](#troubleshooting.cannot-connect.different-regions)
+ [Connessione da diversi Amazon VPCs](#troubleshooting.cannot-connect.different-vpcs)
+ [Il gruppo di sicurezza blocca le connessioni in entrata](#troubleshooting.cannot-connect.inbound-not-allowed)
+ [Problema relativo alle preferenze di lettura del driver Java Mongo](#troubleshooting-cannot-connect-java-mongo-issue)
### Connessione da endpoint pubblici
**Stai tentando di connetterti a un cluster Amazon DocumentDB direttamente dal tuo laptop o macchina di sviluppo locale.**
Il tentativo di connettersi a un cluster Amazon DocumentDB direttamente da un endpoint pubblico, come un laptop o una macchina di sviluppo locale, avrà esito negativo. Amazon DocumentDB è disponibile solo su cloud privato virtuale (VPC) e attualmente non supporta endpoint pubblici. Pertanto, non è possibile connettersi direttamente al cluster Amazon DocumentDB dal laptop o dall'ambiente di sviluppo locale al di fuori del VPC.
Per connetterti a un cluster Amazon DocumentDB dall'esterno di un Amazon VPC, puoi utilizzare un tunnel SSH. Per ulteriori informazioni, consulta [Connessione a un cluster Amazon DocumentDB dall'esterno di un Amazon VPC](connect-from-outside-a-vpc.md). Inoltre, se il tuo ambiente di sviluppo si trova in un altro Amazon VPC, puoi anche utilizzare VPC Peering e connetterti al tuo cluster Amazon DocumentDB da un altro Amazon VPC nella stessa regione o in una regione diversa.
### Connessioni tra regioni
**Stai tentando di connetterti a un cluster Amazon DocumentDB in un'altra regione.**
Se tenti di connetterti a un cluster Amazon DocumentDB da un'istanza Amazon EC2 in una regione diversa dalla regione del cluster, ad esempio, provando a connetterti a un cluster nella regione Stati Uniti orientali (Virginia settentrionale) (us-east-1) dalla regione Stati Uniti occidentali (Oregon) (us-west-2), la connessione avrà esito negativo.
Per verificare la regione del cluster Amazon DocumentDB, esegui il comando seguente. La regione è nell'endpoint.
```
aws docdb describe-db-clusters \
--db-cluster-identifier sample-cluster \
--query 'DBClusters[*].Endpoint'
```
L'aspetto dell'output di questa operazione è simile al seguente.
```
[
"sample-cluster.node.us-east-1.docdb.amazonaws.com"
]
```
Per verificare la regione dell'istanza EC2, esegui il comando seguente.
```
aws ec2 describe-instances \
--query 'Reservations[*].Instances[*].Placement.AvailabilityZone'
```
L'aspetto dell'output di questa operazione è simile al seguente.
```
[
[
"us-east-1a"
]
]
```
### Connessione da diversi Amazon VPCs
**Stai tentando di connetterti a un cluster Amazon DocumentDB da un VPC diverso da quello su cui è distribuito il cluster.**
Se il cluster Amazon DocumentDB e l'istanza Amazon EC2 si trovano nello stesso cluster Amazon DocumentDB ma non Regione AWS nello stesso Amazon VPC, non è possibile connettersi direttamente al cluster Amazon DocumentDB a meno che non sia abilitato il peering VPC tra i due Amazon. VPCs
Per verificare l'Amazon VPC della tua istanza Amazon DocumentDB, esegui il comando seguente.
```
aws docdb describe-db-instances \
--db-instance-identifier sample-instance \
--query 'DBInstances[*].DBSubnetGroup.VpcId'
```
Per verificare l'Amazon VPC della tua istanza Amazon EC2, esegui il comando seguente.
```
aws ec2 describe-instances \
--query 'Reservations[*].Instances[*].VpcId'
```
### Il gruppo di sicurezza blocca le connessioni in entrata
**Stai tentando di connetterti a un cluster Amazon DocumentDB e il gruppo di sicurezza del cluster non consente connessioni in entrata sulla porta del cluster (porta predefinita: 27017).**
Supponiamo che il cluster Amazon DocumentDB e l'istanza Amazon EC2 si trovino entrambi nella stessa regione e Amazon VPC e utilizzino lo stesso gruppo di sicurezza Amazon VPC. Se non riesci a connetterti al cluster Amazon DocumentDB, la causa probabile è che il gruppo di sicurezza (ovvero il firewall) del cluster non consente connessioni in entrata sulla porta scelta per il cluster Amazon DocumentDB (la porta predefinita è 27017).
Per verificare la porta per il tuo cluster Amazon DocumentDB, esegui il comando seguente.
```
aws docdb describe-db-clusters \
--db-cluster-identifier sample-cluster \
--query 'DBClusters[*].[DBClusterIdentifier,Port]'
```
Per impostare il gruppo di sicurezza Amazon DocumentDB per il cluster, esegui il comando seguente.
```
aws docdb describe-db-clusters \
--db-cluster-identifier sample-cluster \
--query 'DBClusters[*].[VpcSecurityGroups[*],VpcSecurityGroupId]'
```
Per verificare le regole in entrata per il tuo gruppo di sicurezza, consulta i seguenti argomenti nella documentazione di Amazon EC2:
+ [Autorizzazione del traffico in entrata per le tue istanze Linux](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/authorizing-access-to-an-instance.html)
+ [Autorizzazione del traffico in entrata per le istanze Windows](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/authorizing-access-to-an-instance.html)
### Problema relativo alle preferenze di lettura del driver Java Mongo
**Le preferenze di lettura del client non vengono rispettate e alcuni client non possono scrivere su Amazon DocumentDB dopo il failover a meno che non vengano riavviati.**
Questo problema, scoperto per la prima volta in Java Mongo Driver 3.7.x, si verifica quando un client stabilisce una connessione ad Amazon DocumentDB utilizzando `MongoClientSettings` e, in particolare, durante il concatenamento del metodo. `applyToClusterSettings` Le impostazioni del MongoClient cluster possono essere definite utilizzando diversi metodi, ad esempio, e. `hosts()` `requiredReplicaSetName()` `mode()`
Quando il client specifica un solo host nel `hosts()` metodo, la modalità viene impostata su `ClusterConnectionMode.SINGLE` anziché su `ClusterConnectionMode.MULTIPLE` Ciò fa sì che il client ignori la preferenza di lettura e si connetta solo al server configurato in. `hosts()` Quindi, anche se le impostazioni del client sono inizializzate come di seguito, tutte le letture andrebbero comunque al primario anziché al secondario.
```
final ServerAddress serverAddress0 = new ServerAddress("cluster-endpoint", 27317));
final MongoCredential credential = MongoCredential.createCredential("xxx",
"admin", "xxxx".toCharArray());
final MongoClientSettings settings = MongoClientSettings.builder()
.credential(credential)
.readPreference(ReadPreference.secondaryPreferred())
.retryWrites(false)
.applyToSslSettings(builder -> builder
.enabled(false))
.applyToClusterSettings(builder -> builder.hosts(
Arrays.asList(serverAddress0
))
.requiredReplicaSetName("rs0"))
.build();
MongoClient mongoClient = MongoClients.create(settings);
```
**Caso di failover**
Utilizzando le impostazioni di connessione client di cui sopra, in caso di failover e aggiornamento ritardato del record DNS per l'endpoint del cluster writer, il client proverebbe comunque a inviare scritture al vecchio writer (ora lettore dopo il failover). Ciò si traduce in un errore lato server (non primario) che non viene gestito in modo appropriato dal driver Java (questo è ancora oggetto di indagine). Pertanto, il client può rimanere in cattivo stato fino al riavvio del server delle applicazioni, ad esempio.
A tale scopo sono disponibili due soluzioni alternative:
+ I client che si connettono ad Amazon DocumentDB tramite una stringa di connessione non avranno questo problema, poiché `ClusterConnectionMode` verrà impostato su `MULTIPLE` quando si imposta la preferenza di lettura.
```
MongoClientURI mongoClientURI = new MongoClientURI("mongodb://usr:pass:cluster-endpoint:27317/test?ssl=false&replicaSet=rs0&readpreference=secondaryPreferred");
MongoClient mongoClient = MongoClients.create(mongoClientURI.getURI());
```
Oppure usando `MongoClientSettings` builder con il `applyConnectionString` metodo.
```
final MongoClientSettings settings = MongoClientSettings.builder()
.credential(credential)
.applyConnectionString(new ConnectionString("usr:pass:cluster-endpoint:27317/test?ssl=false&replicaSet=rs0&readpreference=secondaryPreferred"))
.retryWrites(false)
.applyToSslSettings(builder → builder
.enabled(false))
.build();
MongoClient mongoClient = MongoClients.create(settings);
```
+ Impostato esplicitamente su`ClusterConnectionMode`. `MULTIPLE` È necessario solo quando si utilizza `applyToClusterSettings` e`hosts().size() == 1`.
```
final ServerAddress serverAddress0 = new ServerAddress("cluster-endpoint", 27317));
final MongoCredential credential = MongoCredential.createCredential("xxx","admin", "xxxx".toCharArray());
final MongoClientSettings settings = MongoClientSettings.builder()
.credential(credential)
.readPreference(ReadPreference.secondaryPreferred())
.retryWrites(false)
.applyToSslSettings(builder → builder
.enabled(false))
.applyToClusterSettings(builder → builder
.hosts(Arrays.asList(serverAddress0))
.requiredReplicaSetName("rs0"))
.mode(ClusterConnectionMode.MULTIPLE))
.build();
MongoClient mongoClient = MongoClients.create(settings);
```
## Test di una connessione a un'istanza Amazon DocumentDB
Puoi verificare la connessione a un cluster utilizzando strumenti comuni di Linux o Windows.
Da un terminale Linux o Unix, puoi eseguire il test della connessione immettendo quanto segue (sostituisci `cluster-endpoint` con l'endpoint e `port` con la porta dell'istanza database):
```
nc -zv cluster-endpoint port
```
Di seguito è riportata un'operazione di esempio e il valore restituito:
```
nc -zv docdbTest.d4c7nm7stsfc0.us-west-2.docdb.amazonaws.com 27017
Connection to docdbTest.d4c7nm7stsfc0.us-west-2.docdb.amazonaws.com 27017 port [tcp/*] succeeded!
```
## Connessione a un endpoint non valido
Quando ci si connette a un cluster Amazon DocumentDB e si utilizza un endpoint del cluster non valido, viene visualizzato un errore simile al seguente.
```
mongo --ssl \
--host sample-cluster.node.us-east-1.docdb.amazonaws.com:27017 \
--sslCAFile global-bundle.pem \
--username \
--password
```
L'output sarà il seguente:
```
MongoDB shell version v3.6
connecting to: mongodb://sample-cluster.node.us-east-1.docdb.amazonaws.com:27017/
2018-11-14T17:21:18.516-0800 I NETWORK [thread1] getaddrinfo("sample-cluster.node.us-east-1.docdb.amazonaws.com") failed:
nodename nor servname provided, or not known 2018-11-14T17:21:18.537-0800 E QUERY [thread1] Error: couldn't initialize
connection to host sample-cluster.node.us-east-1.docdb.amazonaws.com, address is invalid :
connect@src/mongo/shell/mongo.js:237:13@(connect):1:6
exception: connect failed
```
Per ottenere l'endpoint valido per un cluster, esegui il comando seguente:
```
aws docdb describe-db-clusters \
--db-cluster-identifier sample-cluster \
--query 'DBClusters[*].[Endpoint,Port]'
```
Per ottenere l'endpoint valido per un'istanza, esegui il comando seguente:
```
aws docdb describe-db-instances \
--db-instance-identifier sample-instance \
--query 'DBInstances[*].[Endpoint.Address,Endpoint.Port]'
```
Per ulteriori informazioni, consulta [Comprendere gli endpoint di Amazon DocumentDB](endpoints.md).
## Configurazione del driver che influisce sul numero di connessioni
Quando si utilizza il driver client per connettersi a un cluster Amazon DocumentDB, è importante considerare il parametro di `maxPoolSize` configurazione. L'`maxPoolSize`impostazione determina il numero massimo di connessioni che il driver client manterrà nel proprio pool di connessioni.
# Risoluzione dei problemi relativi agli indici
I seguenti argomenti spiegano come agire in caso di mancata creazione dell'indice o indice in background.
**Topics**
+ [La compilazione dell'indice non riesce](#troubleshooting.index-build-fails)
+ [L'indice in background genera problemi di latenza e fallisce](#troubleshooting.background-index-build-fails)
+ [Incremento dell'indice del database](#troubleshooting-database-bloat)
## La compilazione dell'indice non riesce
Amazon DocumentDB utilizza lo storage locale su un'istanza come parte del processo di creazione dell'indice. Puoi monitorare questo utilizzo del disco utilizzando il **FreeLocalStorage** CloudWatch metric (). `CloudWatch -> Metrics -> DocDB -> Instance Metrics` Quando la creazione di un indice consuma tutto il disco locale e ha esito negativo, riceverai un errore. Durante la migrazione dei dati su Amazon DocumentDB, ti consigliamo di creare prima gli indici e poi inserire i dati. Per ulteriori informazioni sulle strategie di migrazione e sulla creazione di indici, consulta [Migrazione ad Amazon DocumentDB](docdb-migration.md) la documentazione di Amazon DocumentDB e il blog: [Migrate da MongoDB ad Amazon DocumentDB utilizzando il metodo](https://aws.amazon.com/blogs/database/migrate-from-mongodb-to-amazon-documentdb-using-the-offline-method/) offline.
Quando si creano indici su un cluster esistente, se la creazione dell'indice impiega più tempo del previsto o non riesce, si consiglia di ridimensionare l'istanza per creare l'indice e poi, dopo la creazione dell'indice, di ridurla. Amazon DocumentDB consente di scalare rapidamente le dimensioni delle istanze in pochi minuti utilizzando Console di gestione AWS o il. AWS CLI Per ulteriori informazioni, consulta [Gestione delle classi di istanze](db-instance-classes.md). Grazie ai prezzi delle istanze al secondo, paghi solo per la risorsa che utilizzi al secondo.
## L'indice in background genera problemi di latenza e fallisce
Le compilazioni di indici in background in Amazon DocumentDB non vengono avviate fino al completamento dell'esecuzione di tutte le query sull'istanza primaria iniziate prima dell'inizio della creazione dell'indice. Se la query viene eseguita a lungo, le compilazioni degli indici in background si bloccheranno fino al termine della query e quindi il completamento potrebbe richiedere più tempo del previsto. Questo è vero anche se le raccolte sono vuote.
Le build di indici in primo piano non presentano lo stesso comportamento di blocco. Invece, le build di indici in primo piano bloccano in modo esclusivo la raccolta fino al completamento della creazione dell'indice. Pertanto, per creare indici su una raccolta vuota ed evitare il blocco di eventuali query di lunga durata, suggeriamo di utilizzare build di indici in primo piano.
**Nota**
Amazon DocumentDB consente la creazione di un solo indice in background su una raccolta alla volta. Se le operazioni DDL (Data Definition Language) come `createIndex()` o `dropIndex()` vengono eseguite sulla stessa raccolta durante la creazione di un indice in background, tale creazione non riesce.
## Incremento dell'indice del database
Amazon DocumentDB utilizza Multi-Version Concurrency Control (MVCC) per gestire transazioni simultanee. Quando i documenti vengono eliminati o aggiornati, le versioni precedenti rimangono nelle raccolte e negli indici come versioni «morte». Il processo di raccolta dei rifiuti recupera automaticamente lo spazio da queste versioni non funzionanti per operazioni future.
Il gonfiamento dell'indice si verifica quando gli indici di una raccolta diventano più grandi a causa dell'accumulo di voci di indice non più valide o obsolete o della frammentazione all'interno delle pagine. La percentuale riportata rappresenta la quantità di spazio indicizzato che può essere utilizzata dalle future voci dell'indice. Questo bloat consuma spazio sia nella cache del buffer che nella memoria. Se vuoi rimuovere il bloat, dovrai ricostruire gli indici.
**Example Esempio**
Esegui il comando seguente per determinare lo spazio di archiviazione inutilizzato per l'indice:
```
db.coll.aggregate({$indexStats:{}});
```
Il risultato è simile al seguente:
```
{
"name" : "_id_",
"key" : {
"_id" : 1
},
"host" : "devbox-test.localhost.a2z.com:27317",
"size" : NumberLong(827392),
"accesses" : {
"ops" : NumberLong(40000),
"docsRead" : NumberLong(46049),
"since" : ISODate("2025-04-03T21:44:51.251Z")
},
"cacheStats" : {
"blksRead" : NumberLong(264),
"blksHit" : NumberLong(140190),
"hitRatio" : 99.8121
},
"unusedStorageSize" : {
"unusedSizeBytes" : 409600,
"unusedSizePercent" : 49.51
}
}
```
È possibile ricostruire gli indici senza tempi di inattività utilizzando il `reIndex` comando, che richiede una scansione dell'intera raccolta. Per informazioni, consulta [Manutenzione dell'indice utilizzando `reIndex`](managing-indexes.md#reIndex).
# Risoluzione dei problemi relativi alle prestazioni e all'utilizzo delle risorse
Questa sezione fornisce domande e soluzioni per problemi di diagnostica comuni nelle distribuzioni di Amazon DocumentDB. Gli esempi forniti utilizzano la *shell Mongo* e si riferiscono a una singola istanza. Per trovare un endpoint dell'istanza, consulta [Comprendere gli endpoint di Amazon DocumentDB](endpoints.md).
**Topics**
+ [Come posso determinare il numero di operazioni di inserimento, aggiornamento ed eliminazione eseguite sulla mia raccolta tramite l'API Mongo?](#user-diag-performed-operations)
+ [Come posso analizzare le prestazioni della cache?](#user-diag-cache-perf)
+ [Come posso trovare e terminare le query bloccate o dalla prolungata esecuzione?](#user_diagnostics-query_terminating)
+ [Come posso visualizzare un piano di query e ottimizzare una query?](#user_diagnostics-query_plan)
+ [Come posso visualizzare un piano di query in cluster elastici?](#user-diagnostics-ec-query-plan)
+ [Come posso creare un elenco di tutte le operazioni in esecuzione su un'istanza?](#user_diagnostics-list_queries)
+ [Come faccio a sapere quando una query sta facendo progressi?](#user_diagnostics-query_progressing)
+ [Come posso determinare il motivo per cui un sistema funziona improvvisamente lentamente?](#user_diagnostics-speed_change)
+ [Come posso determinare la causa dell'elevato utilizzo della CPU su una o più istanze del cluster?](#user_diagnostics-cpu_utilization)
+ [Come posso determinare i cursori aperti su un'istanza?](#user_diagnostics-open_cursors)
+ [Come posso determinare la versione corrente del motore Amazon DocumentDB?](#user_diagnostics-engine_version)
+ [Come posso analizzare l'utilizzo degli indici e identificare gli indici non utilizzati?](#user-diag-index-usage)
+ [Come posso identificare gli indici mancanti?](#user_diagnostics-identify_missing_indexes)
+ [Come posso determinare il volume della raccolta di database?](#performance-collection-bloat)
+ [Riepilogo delle domande utili](#user_diagnostics-useful_queries)
## Come posso determinare il numero di operazioni di inserimento, aggiornamento ed eliminazione eseguite sulla mia raccolta tramite l'API Mongo?
Per visualizzare il numero di operazioni di inserimento, aggiornamento ed eliminazione eseguite su una determinata raccolta, esegui il seguente comando su quella raccolta:
```
db.collection.stats()
```
L'output di questo comando descrive quanto segue nel suo `opCounters` campo:
+ **numDocsIns**- Il numero di documenti inseriti in questa raccolta. Ciò include i documenti inseriti utilizzando i `insertMany` comandi `insert` and, nonché i documenti inseriti da un upsert.
+ **numDocsUpd**- Il numero di aggiornamenti dei documenti in questa raccolta. Ciò include i documenti aggiornati utilizzando i `findAndModify` comandi `update` and.
+ **numDocsDel**- Il numero di documenti eliminati da questa raccolta. Sono inclusi i documenti eliminati utilizzando i `findAndModify` comandi `deleteOne` `deleteMany``remove`,, e.
+ **LastReset**: l'ora in cui questi contatori sono stati reimpostati l'ultima volta. Le statistiche fornite da questo comando vengono reimpostate durante starting/stopping il cluster o il ridimensionamento up/down dell'istanza.
Di seguito `db.collection.stats()` è riportato un esempio di output dell'esecuzione.
```
{
"ns" : "db.test",
"count" : ...,
"size" : ...,
"avgObjSize" : ...,
"storageSize" : ...,
"capped" : false,
"nindexes" : ...,
"totalIndexSize" : ...,
"indexSizes" : {
"_id_" : ...,
"x_1" : ...
},
"collScans" : ...,
"idxScans" : ...,
"opCounter" : {
"numDocsIns" : ...,
"numDocsUpd" : ...,
"numDocsDel" : ...
},
"cacheStats" : {
"collBlksHit" : ...,
"collBlksRead" : ..,
"collHitRatio" : ...,
"idxBlksHit" : ...,
"idxBlksRead" : ...,
"idxHitRatio" : ...
},
"lastReset" : "2022-09-02 19:41:40.471473+00",
"ok" : 1,
"operationTime" : Timestamp(1662159707, 1)
}
```
Questo comando stats deve essere usato quando si visualizzano contatori specifici della raccolta per le operazioni di inserimento, aggiornamento ed eliminazione tramite l'API Mongo. Un altro modo per visualizzare i contatori delle operazioni specifici della raccolta consiste nell'abilitare il controllo DML. Il numero di operazioni di inserimento, aggiornamento ed eliminazione su tutte le raccolte durante intervalli di un minuto può essere visualizzato in. [Monitoraggio di Amazon DocumentDB con CloudWatch](cloud_watch.md)
## Come posso analizzare le prestazioni della cache?
L'analisi delle prestazioni della cache può fornire informazioni sull'efficienza del recupero dei dati e sulle prestazioni del sistema e si basa sulla quantità di dati letti dal disco rispetto alla cache. Forniamo statistiche sulla cache sul numero di accessi alla cache (dati letti dalla cache) e errori di cache (dati che non si trovano nella cache e letti dal disco) per fornire informazioni sulle prestazioni della cache. Le statistiche della cache per una raccolta specifica possono essere trovate eseguendo il seguente comando su quella raccolta:
```
db.collection.stats()
```
I valori nel `cacheStats` campo nell'output di questo comando forniscono le statistiche della cache per la raccolta e le statistiche totali della cache per gli indici creati nella raccolta. Queste statistiche sono elencate di seguito:
+ **`collBlksHit`**- Il numero di blocchi letti dalla cache durante le operazioni su questa raccolta.
+ **`collBlksRead`**- Il numero di blocchi letti dal disco (cache mancante) durante le operazioni su questa raccolta.
+ **`collHitRatio`**- Il rapporto di accesso alla cache per questa raccolta (`100 * [collBlksHit / (collBlksHit + collBlksRead)]`).
+ **`idxBlksHit`**- Il numero di blocchi letti dalla cache per ogni indice creato su questa raccolta.
+ **`idxBlksRead`**- Il numero di blocchi letti dal disco (mancanti nella cache) per ogni indice creato su questa raccolta.
+ **`idxHitRatio`**- Il rapporto di accessi alla cache per gli indici creati su questa raccolta (). `100 * [idxBlksHit / (idxBlksHit + idxBlksRead)]`
+ **`lastReset`**- L'ora in cui queste statistiche sono state reimpostate l'ultima volta. Le statistiche fornite da `db.collection.stats()` vengono reimpostate starting/stopping al momento del cluster o del ridimensionamento up/down dell'istanza.
Utilizzando il comando è inoltre possibile trovare una suddivisione dei `idxBlksRead` campi `idxBlksHit` e per ogni indice. `indexStats` Le statistiche sulla cache specifiche dell'indice possono essere trovate eseguendo il comando seguente:
```
db.collection.aggregate([{$indexStats:{}}]).pretty()
```
Per ogni indice, nel `cacheStats` campo sono disponibili le seguenti statistiche sulla cache:
+ **`blksHit`**- Il numero di blocchi letti dalla cache per questo indice.
+ **`blksRead`**- Il numero di blocchi letti dal disco per questo indice.
+ **`blksHitRatio`**- Il rapporto di accesso alla cache arrotondato a quattro cifre decimali, calcolato da. `100 * [blksHit / (blksHit + blksRead)]`
## Come posso trovare e terminare le query bloccate o dalla prolungata esecuzione?
Le query degli utenti possono essere eseguite lentamente a causa di un piano di query non ottimale o possono essere bloccate a causa di conflitti tra risorse.
Per trovare le query con esecuzione prolungata che rallentano a causa di un piano di query non ottimale o le query bloccate a causa di conflitti tra risorse, utilizza il comando `currentOp`. Puoi applicare filtri al comando per ridurre l'elenco delle query pertinenti da terminare. È necessario che `opid` sia associato alla query con esecuzione prolungata per poterla terminare.
La query seguente utilizza il comando `currentOp` per elencare tutte le query bloccate o in esecuzione per più di 10 secondi.
```
db.adminCommand({
aggregate: 1,
pipeline: [
{$currentOp: {}},
{$match:
{$or: [
{secs_running: {$gt: 10}},
{WaitState: {$exists: true}}]}},
{$project: {_id:0, opid: 1, secs_running: 1}}],
cursor: {}
});
```
Quindi, puoi restringere la query per trovare l'`opid` di una query in esecuzione per più di 10 secondi e terminarla.
**Per trovare e terminare una query in esecuzione da più di 10 secondi**
1. Trovare l'`opid` della query.
```
db.adminCommand({
aggregate: 1,
pipeline: [
{$currentOp: {}},
{$match:
{$or:
[{secs_running: {$gt: 10}},
{WaitState: {$exists: true}}]}}],
cursor: {}
});
```
L'aspetto dell'output di questa operazione è simile al seguente (formato JSON).
```
{
"waitedMS" : NumberLong(0),
"cursor" : {
"firstBatch" : [
{
"opid" : 24646,
"secs_running" : 12
}
],
"id" : NumberLong(0),
"ns" : "admin.$cmd"
},
"ok" : 1
}
```
1. Terminare la query utilizzando l'operazione `killOp`.
```
db.adminCommand({killOp: 1, op: 24646});
```
## Come posso visualizzare un piano di query e ottimizzare una query?
Il rallentamento dell'elaborazione di una query può essere dovuto a un'esecuzione che richiede una scansione completa della raccolta per selezionare i documenti pertinenti. Talvolta, creare indici appropriati consente di accelerare l'esecuzione di una query. Per rilevare questo tipo di scenario e stabilire i campi per cui creare degli indici, puoi usare il comando `explain`.
**Nota**
Amazon DocumentDB emula l'API MongoDB 3.6 su un motore di database appositamente progettato che utilizza un sistema di storage distribuito, con tolleranza ai guasti e riparazione automatica. Di conseguenza, i piani di interrogazione e l'output di `explain()` possono differire tra Amazon DocumentDB e MongoDB. I clienti che desiderano il controllo sul piano di query possono utilizzare l'operatore `$hint` per applicare la selezione di un indice preferito.
Esegui la query che vuoi ottimizzare con il comando `explain` come segue.
```
db.runCommand({explain: {}})
```
Di seguito è riportato un esempio di operazione.
```
db.runCommand({explain:{
aggregate: "sample-document",
pipeline: [{$match: {x: {$eq: 1}}}],
cursor: {batchSize: 1}}
});
```
L'aspetto dell'output di questa operazione è simile al seguente (formato JSON).
```
{
"queryPlanner" : {
"plannerVersion" : 1,
"namespace" : "db.test",
"winningPlan" : {
"stage" : "COLLSCAN"
}
},
"serverInfo" : {
"host" : "...",
"port" : ...,
"version" : "..."
},
"ok" : 1
}
```
L'output precedente indica che la fase `$match` richiede la scansione delle raccolte complete e di verificare che il campo `"x"` di ciascun documento corrisponda a 1. Se la raccolta annovera molti documenti, la sua scansione e, di conseguenza, l'elaborazione completa della query sono molto lente. La presenza di `"COLLSCAN"` nell'output del comando `explain` indica che le prestazioni della query possono migliorare creando indici appropriati.
In questo esempio, la query verifica se il campo `"x"` è uguale a 1 in tutti i documenti. Pertanto, la creazione di un indice sul campo `"x"` consente alla query di evitare la scansione completa della raccolta e di utilizzare l'indice per restituire i documenti pertinenti in meno tempo.
Dopo aver creato un indice sul campo `"x"`, l'output di `explain` è il seguente.
```
{
"queryPlanner" : {
"plannerVersion" : 1,
"namespace" : "db.test",
"winningPlan" : {
"stage" : "IXSCAN",
"indexName" : "x_1",
"direction" : "forward"
}
},
"serverInfo" : {
"host" : "...",
"port" : ...,
"version" : "..."
},
"ok" : 1
}
```
La creazione di un indice sul campo `"x"` ha permesso alla fase `$match` di avviare una scansione dell'indice e ridurre il numero di documenti per cui valutare il predicato `"x = 1"`.
Per raccolte di piccole dimensioni, il processore di query Amazon DocumentDB può scegliere di non utilizzare un indice se i miglioramenti delle prestazioni sono trascurabili.
## Come posso visualizzare un piano di query in cluster elastici?
Per esaminare un piano di query in cluster elastici, usa il `explain` comando. Di seguito è riportato un esempio di `explain` operazione su una query di ricerca destinata a una raccolta frammentata:
```
db.runCommand(
{
explain: { find: "cities", filter: {"name": "Seoul"}}
}
)
```
**Nota**
Amazon DocumentDB emula MongoDB su un motore di database creato appositamente. Di conseguenza, i piani di interrogazione e l'output di `explain()` possono differire tra Amazon DocumentDB e MongoDB. Puoi controllare il piano di interrogazione utilizzando l'`$hint`operatore per imporre la selezione di un indice preferito.
L'output di questa operazione può essere simile al seguente (formato JSON):
```
{
"queryPlanner" : {
"elasticPlannerVersion" : 1,
"winningPlan" : {
"stage" : "SINGLE_SHARD",
"shards" : [
{
"plannerVersion" : 1,
"namespace" : "population.cities",
"winningPlan" : {
"stage" : "SHARD_MERGE",
"shards" : [
{
"shardName" : "f2cf5cfd-fe9c-40ca-b4e5-298ca0d11111",
"plannerVersion" : 1,
"namespace" : "population.cities",
"winningPlan" : {
"stage" : "PARTITION_MERGE",
"inputStages" : [
{
"stage" : "COLLSCAN",
"partitionCount" : 21
}
]
}
},
{
"shardName" : "8f3f80e2-f96c-446e-8e9d-aab8c7f22222",
"plannerVersion" : 1,
"namespace" : "population.cities",
"winningPlan" : {
"stage" : "PARTITION_MERGE",
"inputStages" : [
{
"stage" : "COLLSCAN",
"partitionCount" : 21
}
]
}
},
{
"shardName" : "32c5a06f-1b2b-4af1-8849-d7c4a033333",
"plannerVersion" : 1,
"namespace" : "population.cities",
"winningPlan" : {
"stage" : "PARTITION_MERGE",
"inputStages" : [
{
"stage" : "COLLSCAN",
"partitionCount" : 22
}
]
}
}
]
},
"shardName" : "32c5a06f-1b2b-4af1-8849-d7c4a0f3fb58"
}
]
}
},
"serverInfo" : {
"host" : "example-4788267630.us-east-1.docdb-elastic.amazonaws.com:27017",
"version" : "5.0.0"
},
"ok" : 1,
"operationTime" : Timestamp(1695097923, 1)
}
```
L'output precedente mostra il piano di interrogazione per la `find` query su un cluster a tre shard. Ogni shard ha più partizioni di dati che possono avere fasi di input diverse. In questo esempio, viene eseguita una «COLLSCAN» (una scansione della raccolta) su tutte le partizioni prima che i risultati vengano uniti nella fase «PARTITION\$1MERGE» all'interno di ogni shard. I risultati degli shard vengono quindi uniti nella fase» SHARD\$1MERGE» prima di essere rispediti al client.
## Come posso creare un elenco di tutte le operazioni in esecuzione su un'istanza?
In qualità di utente o utente principale, spesso si desidera elencare tutte le operazioni correnti in esecuzione su un'istanza per scopi di diagnostica e risoluzione dei problemi. Per ulteriori informazioni sulla gestione degli utenti, consulta [Gestione degli utenti di Amazon DocumentDB](security.managing-users.md).
Con la `mongo` shell, puoi utilizzare la seguente query per elencare tutte le operazioni in esecuzione su un'istanza Amazon DocumentDB.
```
db.adminCommand({currentOp: 1, $all: 1});
```
La query restituisce l'elenco completo di tutte le query e le attività interne del sistema attualmente operative nell'istanza.
L'aspetto dell'output di questa operazione è simile al seguente (formato JSON).
```
{
"inprog" : [
{
"desc" : "INTERNAL"
},
{
"desc" : "TTLMonitor",
"active" : false
},
{
"client" : ...,
"desc" : "Conn",
"active" : true,
"killPending" : false,
"opid" : 195,
"ns" : "admin.$cmd",
"command" : {
"currentOp" : 1,
"$all" : 1
},
"op" : "command",
"$db" : "admin",
"secs_running" : 0,
"microsecs_running" : NumberLong(68),
"clientMetaData" : {
"application" : {
"name" : "MongoDB Shell"
},
"driver" : {
...
},
"os" : {
...
}
}
},
{
"desc": "GARBAGE_COLLECTION",
"garbageCollection": {
"databaseName": "testdb",
"collectionName": "testCollectionA"
},
"secs_running": 3,
"microsecs_running": NumberLong(3123456)
},
{
"desc": "GARBAGE_COLLECTION",
"garbageCollection": {
"databaseName": "testdb",
"collectionName": "testCollectionB"
},
"secs_running": 4,
"microsecs_running": NumberLong(4123456)
}
],
"ok" : 1
}
```
Di seguito sono riportati i valori validi per il campo `"desc"`.
+ **INTERNAL**— Attività interne al sistema come la pulizia del cursore o le attività di pulizia degli utenti non aggiornate.
+ **TTLMonitor**— Il thread di monitoraggio Time to Live (TTL). Il suo stato di esecuzione si riflette nel campo `"active"`.
+ **GARBAGE\$1COLLECTION**— Il thread interno del Garbage Collector.
+ **CONN**— La richiesta dell'utente.
+ **CURSOR**— L'operazione è un cursore inattivo che attende che l'utente chiami il comando «getMore» per ottenere il successivo batch di risultati. In questo stato, il cursore consuma memoria, ma non consuma alcuna elaborazione.
L'output precedente elenca, inoltre, tutte le query degli utenti in esecuzione nel sistema. Ogni query viene eseguita in un contesto formato da un database e una raccolta, detto *spazio dei nomi*. Lo spazio dei nomi di una query è disponibile nel campo `"ns"`.
A volte è necessario elencare tutte le query degli utenti in esecuzione in un determinato spazio dei nomi. Pertanto, l'output precedente deve essere filtrato in base al campo `"ns"`. Di seguito è riportato un esempio di query per filtrare l'output. La query elenca tutte le query degli utenti attualmente in esecuzione nel database `"db"` e nella raccolta `"test"` (ovvero lo spazio dei nomi `"db.test"`).
```
db.adminCommand({aggregate: 1,
pipeline: [{$currentOp: {allUsers: true, idleConnections: true}},
{$match: {ns: {$eq: "db.test"}}}],
cursor: {}
});
```
In qualità di utente principale del sistema, puoi visualizzare le domande di tutti gli utenti e anche tutte le attività interne del sistema. Tutti gli altri utenti, invece, possono vedere solo le rispettive query.
Se il numero totale di query e attività di sistema non rientra nelle dimensioni predefinite del cursore di batch, la shell `mongo` genera automaticamente un oggetto iteratole `'it'` che consente di visualizzare il resto dei risultati. Bisogna mantenere in esecuzione il comando `'it'` fino a esaurimento dei risultati.
## Come faccio a sapere quando una query sta facendo progressi?
Le query degli utenti possono essere eseguite lentamente a causa di un piano di query non ottimale o possono essere bloccate a causa di conflitti tra risorse. Il debug di questo tipo di query è un processo in più fasi che può richiedere di ripetere più volte una stessa operazione.
Innanzitutto, ai fini del debug, occorre elencare tutte le query bloccate o dall'esecuzione prolungata. La query seguente elenca tutte le query utente che sono state in esecuzione per più di 10 secondi o che sono in attesa di risorse.
```
db.adminCommand({aggregate: 1,
pipeline: [{$currentOp: {}},
{$match: {$or: [{secs_running: {$gt: 10}},
{WaitState: {$exists: true}}]}},
{$project: {_id:0,
opid: 1,
secs_running: 1,
WaitState: 1,
blockedOn: 1,
command: 1}}],
cursor: {}
});
```
Ripeti periodicamente la query precedente per determinare se l'elenco delle query cambia e per identificare le query bloccate o con esecuzione prolungata.
L'eventuale presenza del campo `WaitState` nel documento di output della query d'interesse indica che il motivo alla base del blocco o della lenta esecuzione della query è un conflitto tra le risorse. Tale conflitto potrebbe attribuirsi all'I/O, alle attività interne di sistema o ad altre query dell'utente.
L'aspetto dell'output di questa operazione è simile al seguente (formato JSON).
```
{
"waitedMS" : NumberLong(0),
"cursor" : {
"firstBatch" : [
{
"opid" : 201,
"command" : {
"aggregate" : ...
},
"secs_running" : 208,
"WaitState" : "IO"
}
],
"id" : NumberLong(0),
"ns" : "admin.$cmd"
},
"ok" : 1
}
```
L'I/O potrebbe rivelarsi inefficace in presenza di molte query afferenti a raccolte diverse e in esecuzione simultanea sulla stessa istanza o se l'istanza dovesse risultare troppo piccola per il set di dati in cui la query viene eseguita. Se le query sono di sola lettura, puoi mitigare la situazione precedente separando le query per ogni raccolta tra repliche separate. In caso di aggiornamenti simultanei in raccolte diverse o quando l'istanza è troppo piccola per il set di dati, la soluzione di mitigazione consiste nel ridimensionare l'istanza.
Se il conflitto tra le risorse è causato da query di altri utenti, il campo `"blockedOn"` nel documento di output presenta il valore `"opid"` della query responsabile del problema. Avvaliti della voce `"opid"` e segui la concatenazione dei campi `"WaitState"` e `"blockedOn"` di tutte le query per individuare la query all'inizio della catena.
Se l'attività in testa alla catena è un'operazione interna, la soluzione di mitigazione consiste nel terminare la query ed eseguirla nuovamente in un secondo momento.
Di seguito è riportato un output di esempio in cui la query di ricerca è bloccata su un blocco di raccolta di proprietà di un'altra attività.
```
{
"inprog" : [
{
"client" : "...",
"desc" : "Conn",
"active" : true,
"killPending" : false,
"opid" : 75,
"ns" : "...",
"command" : {
"find" : "...",
"filter" : {
}
},
"op" : "query",
"$db" : "test",
"secs_running" : 9,
"microsecs_running" : NumberLong(9449440),
"threadId" : 24773,
"clientMetaData" : {
"application" : {
"name" : "MongoDB Shell"
},
"driver" : {
...
},
"os" : {
...
}
},
"WaitState" : "CollectionLock",
"blockedOn" : "INTERNAL"
},
{
"desc" : "INTERNAL"
},
{
"client" : "...",
...
"command" : {
"currentOp" : 1
},
...
}
],
"ok" : 1
}
```
Se `"WaitState"` presenta i valori `"Latch"`, `"SystemLock"`, `"BufferLock"`, `"BackgroundActivity"` o `"Other"`, il conflitto tra risorse è originato da attività interne di sistema. Se la situazione persiste per un lungo periodo di tempo, l'unica soluzione di mitigazione consiste nel terminare la query ed eseguirla nuovamente in un secondo momento.
## Come posso determinare il motivo per cui un sistema funziona improvvisamente lentamente?
Di seguito sono elencati alcuni motivi comuni del rallentamento del sistema:
+ Eccessivi conflitti delle risorse tra query simultanee
+ Il numero di query simultanee attive aumenta nel tempo
+ Attività interne di sistema, ad esempio `"GARBAGE_COLLECTION"`
Per monitorare l'utilizzo del sistema nel tempo, esegui periodicamente la seguente query `"currentOp"` e trasferisci i risultati su un archivio esterno. La query conta le query e operazioni nei vari spazi dei nomi presenti nel sistema. Puoi analizzare i risultati relativi all'utilizzo del sistema per stabilire il carico del sistema e prendere le decisioni appropriate.
```
db.adminCommand({aggregate: 1,
pipeline: [{$currentOp: {allUsers: true, idleConnections: true}},
{$group: {_id: {desc: "$desc", ns: "$ns", WaitState: "$WaitState"}, count: {$sum: 1}}}],
cursor: {}
});
```
Questa query restituisce un'aggregazione delle query eseguite nei vari spazi dei nomi e di tutte le attività interne di sistema, nonché il numero univoco degli eventuali stati di attesa per spazio dei nomi.
L'aspetto dell'output di questa operazione è simile al seguente (formato JSON).
```
{
"waitedMS" : NumberLong(0),
"cursor" : {
"firstBatch" : [
{
"_id" : {
"desc" : "Conn",
"ns" : "db.test",
"WaitState" : "CollectionLock"
},
"count" : 2
},
{
"_id" : {
"desc" : "Conn",
"ns" : "admin.$cmd"
},
"count" : 1
},
{
"_id" : {
"desc" : "TTLMonitor"
},
"count" : 1
}
],
"id" : NumberLong(0),
"ns" : "admin.$cmd"
},
"ok" : 1
}
```
L'output precedente annovera due query dell'utente nello spazio dei nomi `"db.test"` che sono bloccate a causa di un blocco della raccolta, una query nello spazio dei nomi `"admin.$cmd"` e un'attività `"TTLMonitor"` interna.
Se l'output indica il blocco di molte query in stato di attesa, consulta [Come posso trovare e terminare le query bloccate o dalla prolungata esecuzione?](#user_diagnostics-query_terminating)
## Come posso determinare la causa dell'elevato utilizzo della CPU su una o più istanze del cluster?
Le sezioni seguenti possono aiutarti a identificare la causa dell'elevato utilizzo della CPU da parte delle istanze. I risultati possono variare a seconda del carico di lavoro.
+ Per determinare il motivo per cui un'istanza viene improvvisamente eseguita lentamente, consulta [Come posso determinare il motivo per cui un sistema funziona improvvisamente lentamente?](#user_diagnostics-speed_change)
+ Per identificare e terminare le query con esecuzione prolungata su una determinata istanza, consulta [Come posso trovare e terminare le query bloccate o dalla prolungata esecuzione?](#user_diagnostics-query_terminating)
+ Per capire se una query sta avanzando, consulta [Come faccio a sapere quando una query sta facendo progressi?](#user_diagnostics-query_progressing)
+ Per determinare il motivo per cui l'esecuzione di una query richiede molto tempo, consulta [Come posso visualizzare un piano di query e ottimizzare una query?](#user_diagnostics-query_plan)
+ Per tenere traccia delle query con esecuzione prolungata nel corso del tempo, consulta [Profilazione delle operazioni di Amazon DocumentDB](profiling.md).
A seconda del motivo dell'elevato utilizzo della CPU da parte delle istanze, può essere utile eseguire una o più delle operazioni indicate di seguito.
+ Se l'istanza primaria presenta un elevato utilizzo della CPU diversamente dalle istanze di replica, valuta la possibilità di distribuire il traffico di lettura tra le repliche tramite le impostazioni delle preferenze di lettura del client (ad esempio, `secondaryPreferred`). Per ulteriori informazioni, consulta [Connessione ad Amazon DocumentDB come set di repliche](connect-to-replica-set.md).
L'utilizzo delle repliche per le letture può ottimizzare l'uso delle risorse del cluster consentendo all'istanza primaria di elaborare più traffico di scrittura. Le letture dalle repliche sono consistenti finali.
+ Se l'elevato utilizzo della CPU è il risultato del carico di lavoro di scrittura, la modifica delle dimensioni delle istanze del cluster in un tipo di istanza più grande aumenta il numero di core CPU disponibili per il carico di lavoro. Per ulteriori informazioni, consultare [Istanze](what-is.md#what-is-db-instances) e [Specifiche della classe di istanza](db-instance-classes.md#db-instance-class-specs).
+ Se tutte le istanze del cluster presentano un elevato utilizzo della CPU e il carico di lavoro utilizza le repliche per le letture, l'aggiunta di più repliche al cluster aumenta le risorse disponibili per il traffico di lettura. Per ulteriori informazioni, consulta [Aggiungere un'istanza Amazon DocumentDB a un cluster](db-instance-add.md).
## Come posso determinare i cursori aperti su un'istanza?
Quando sei connesso a un'istanza Amazon DocumentDB, puoi usare il comando `db.runCommand("listCursors")` per elencare i cursori aperti su quell'istanza. Esiste un limite massimo di 4.560 cursori attivi aperti in un dato momento su una determinata istanza di Amazon DocumentDB, a seconda del tipo di istanza. Si consiglia generalmente di chiudere i cursori che non sono più in uso in quanto utilizzano risorse su un'istanza e prevedono un limite massimo. Vedi per i limiti specifici[Quote e limiti di Amazon DocumentDB](limits.md).
```
db.runCommand("listCursors")
```
## Come posso determinare la versione corrente del motore Amazon DocumentDB?
Per determinare la versione corrente del motore Amazon DocumentDB, esegui il comando seguente.
```
db.runCommand({getEngineVersion: 1})
```
L'aspetto dell'output di questa operazione è simile al seguente (formato JSON).
```
{ "engineVersion" : "2.x.x", "ok" : 1 }
```
**Nota**
La versione del motore per Amazon DocumentDB 3.6 è 1.x.x, la versione del motore per Amazon DocumentDB 4.0 è 2.x.x, la versione del motore per Amazon DocumentDB 5.0 è 3.x.x e la versione del motore per Amazon DocumentDB 8.0 è 4.x.x.
## Come posso analizzare l'utilizzo degli indici e identificare gli indici non utilizzati?
Per identificare gli indici per una determinata raccolta, eseguire il comando seguente:
```
db.collection.getIndexes()
```
Per analizzare la quantità di indici utilizzati durante le operazioni eseguite sulle raccolte, è possibile utilizzare i comandi `collStats` and`indexStats`. Per visualizzare il numero totale di scansioni eseguite utilizzando gli indici (index scans) rispetto al numero di scansioni eseguite senza un indice (collection scans), esegui il comando seguente:
```
db.collection.stats()
```
L'output di questo comando include i seguenti valori:
+ **`idxScans`**- Il numero di scansioni eseguite su questa raccolta utilizzando un indice.
+ **`collScans`**- Il numero di scansioni eseguite su questa raccolta senza utilizzare un indice. Queste scansioni avrebbero comportato la ricerca dei documenti della raccolta uno alla volta.
+ **`lastReset`**- L'ora in cui questi contatori sono stati azzerati l'ultima volta. Le statistiche fornite da questo comando vengono reimpostate starting/stopping al momento del cluster o del ridimensionamento up/down dell'istanza.
Un'analisi dettagliata dell'utilizzo di ciascun indice è disponibile nell'output del comando seguente. È consigliabile identificare e rimuovere regolarmente gli indici non utilizzati per migliorare le prestazioni e ridurre i costi, poiché elimina le operazioni di elaborazione e archiviazione non necessarie e l' I/Os utilizzo per la manutenzione degli indici.
```
db.collection.aggregate([{$indexStats:{}}]).pretty()
```
L'output di questo comando fornisce i seguenti valori per ogni indice creato nella raccolta:
+ **`ops`**- Il numero di operazioni che hanno utilizzato l'indice. Se il carico di lavoro è in esecuzione per un periodo sufficientemente lungo e si è certi che il carico di lavoro è in uno stato costante, un valore `ops` pari a zero indica che l'indice non viene utilizzato affatto.
+ **`numDocsRead`**- Il numero di documenti letti durante le operazioni che utilizzano questo indice.
+ **`since`**- Il periodo trascorso da quando Amazon DocumentDB ha iniziato a raccogliere statistiche sull'utilizzo dell'indice, che in genere è il valore dall'ultima operazione di riavvio o manutenzione del database.
+ **`size`**- La dimensione di questo indice in byte.
L'esempio seguente è un esempio di output ottenuto dall'esecuzione del comando precedente:
```
{
"name" : "_id_",
"key" : {
"_id" : 1
},
"host" : "example-host.com:12345",
"size" : NumberLong(...),
"accesses" : {
"ops" : NumberLong(...),
"docsRead" : NumberLong(...),
"since" : ISODate("...")
},
"cacheStats" : {
"blksRead" : NumberLong(...),
"blksHit" : NumberLong(...),
"hitRatio" : ...
}
}
{
"name" : "x_1",
"key" : {
"x" : 1
},
"host" : "example-host.com:12345",
"size" : NumberLong(...),
"accesses" : {
"ops" : NumberLong(...),
"docsRead" : NumberLong(...),
"since" : ISODate("...")
},
"cacheStats" : {
"blksRead" : NumberLong(...),
"blksHit" : NumberLong(...),
"hitRatio" : ...
}
}
```
Per determinare la dimensione complessiva dell'indice per una raccolta, eseguire il comando seguente:
```
db.collection.stats()
```
Per eliminare un indice inutilizzato, eseguire il comando seguente:
```
db.collection.dropIndex("indexName")
```
## Come posso identificare gli indici mancanti?
Puoi utilizzare il [profiler Amazon DocumentDB per registrare le query lente](https://docs.aws.amazon.com//documentdb/latest/developerguide/profiling.html). Una query che viene visualizzata ripetutamente nel log di query lento potrebbe indicare che è necessario un indice aggiuntivo per migliorare le prestazioni della query.
Puoi identificare opportunità di indici utili cercando query di lunga durata che hanno una o più fasi che eseguono almeno una `COLLSCAN` fase, il che significa che la fase di interrogazione deve leggere tutti i documenti della raccolta per fornire una risposta alla query.
Nell'esempio seguente viene illustrata una query su un insieme di corse in taxi eseguite su una raccolta di grandi dimensioni.
```
db.rides.count({"fare.totalAmount":{$gt:10.0}}))
```
Per eseguire questo esempio, la query doveva eseguire una scansione della raccolta (cioè leggere ogni singolo documento nella raccolta) poiché non vi è alcun indice sul campo `fare.totalAmount`. L'output del profiler Amazon DocumentDB per questa query è simile al seguente:
```
{
...
"cursorExhausted": true,
"nreturned": 0,
"responseLength": 0,
"protocol": "op_query",
"millis": 300679,
"planSummary": "COLLSCAN",
"execStats": {
"stage": "COLLSCAN",
"nReturned": "0",
"executionTimeMillisEstimate": "300678.042"
},
"client": "172.31.5.63:53878",
"appName": "MongoDB Shell",
"user": "example"
}
```
Per velocizzare la query in questo esempio, si desidera creare un indice su `fare.totalAmount`, come illustrato di seguito.
```
db.rides.createIndex( {"fare.totalAmount": 1}, {background: true} )
```
**Nota**
Gli indici creati in primo piano (ovvero se l'opzione `{background:true}` non è stata fornita durante la creazione dell'indice) assumono un blocco di scrittura esclusivo, che impedisce alle applicazioni di scrivere dati nella raccolta fino al completamento della compilazione dell'indice. Tenere presente questo potenziale impatto durante la creazione di indici nei cluster di produzione. Quando si creano indici, si consiglia di impostare `{background:true}`.
In generale, si desidera creare indici su campi con elevata cardinalità (ad esempio, un numero elevato di valori univoci). La creazione di un indice su un campo con bassa cardinalità può comportare un indice di grandi dimensioni che non viene utilizzato. L'ottimizzatore di query di Amazon DocumentDB considera la dimensione complessiva della raccolta e la selettività degli indici durante la creazione di un piano di query. In alcuni momenti, l'elaboratore di query selezionerà un `COLLSCAN` anche se è presente un indice. Ciò accade quando l'elaboratore di query stima che l'utilizzo dell'indice non produrrà un vantaggio in termini di prestazioni rispetto alla scansione dell'intera raccolta. Se si desidera forzare l'elaboratore di query affinché utilizzi un particolare indice, è possibile ricorrere all'`hint()` come illustrato di seguito.
```
db.collection.find().hint("indexName")
```
## Come posso determinare il volume della raccolta di database?
Il gonfiamento della raccolta si verifica quando le dimensioni di una raccolta aumentano a causa dell'accumulo di documenti obsoleti o obsoleti o della frammentazione all'interno delle pagine del database. La percentuale riportata rappresenta la quantità di spazio sui documenti che può essere utilizzata dai documenti futuri. Questo bloat consuma spazio sia nella cache del buffer che nella memoria. Per rimuovere il bloat, le raccolte devono essere ricaricate tramite dump/restore o utilizzando un loop-back di migrazione e lo switchover durante una finestra di manutenzione.
**Example Esempio**
Esegui il comando seguente per determinare lo spazio di archiviazione inutilizzato per la tua raccolta:
```
db.runCommand({collStats:'coll'})
```
Il risultato è simile al seguente:
```
{
"ns" : "test.coll",
"count" : 7500,
"size" : 23250,
"avgObjSize" : 31,
"storageSize" : 106496,
"unusedStorageSize" : {
"unusedBytes" : 16384,
"unusedPercent" : 25.12
},
"compression" : {
"enable" : false
},
"capped" : false,
"nindexes" : 1,
"totalIndexSize" : 57344,
"indexSizes" : {
"_id_" : 57344
},
"collScans" : 4,
"idxScans" : 10000,
"opCounter" : {
"numDocsIns" : 1000,
"numDocsUpd" : 0,
"numDocsDel" : 250
},
"cacheStats" : {
"collBlksHit" : 3570,
"collBlksRead" : 8,
"collHitRatio" : 99.7765,
"idxBlksHit" : 12293,
"idxBlksRead" : 6,
"idxHitRatio" : 99.9513
},
"lastReset" : "2024-12-18 00:30:21.552019+00",
"ok" : 1,
"operationTime" : Timestamp(1734632375, 1)
}
```
## Riepilogo delle domande utili
Le seguenti query possono essere utili per monitorare le prestazioni e l'utilizzo delle risorse in Amazon DocumentDB.
+ Utilizza il seguente comando per visualizzare le statistiche su una raccolta specifica, inclusi contatori operativi, statistiche sulla cache, statistiche sugli accessi e statistiche sulle dimensioni:
```
db.collection.stats()
```
+ Utilizzate il comando seguente per visualizzare le statistiche su ogni indice creato in una raccolta, comprese le dimensioni dell'indice, le statistiche sulla cache specifiche dell'indice e le statistiche sull'utilizzo dell'indice:
```
db.collection.aggregate([{$indexStats:{}}]).pretty()
```
+ Utilizza la seguente query per elencare tutte le attività.
```
db.adminCommand({currentOp: 1, $all: 1});
```
+ Il codice seguente elenca tutte le query bloccate o con esecuzione prolungata.
```
db.adminCommand({aggregate: 1,
pipeline: [{$currentOp: {}},
{$match: {$or: [{secs_running: {$gt: 10}},
{WaitState: {$exists: true}}]}},
{$project: {_id:0,
opid: 1,
secs_running: 1,
WaitState: 1,
blockedOn: 1,
command: 1}}],
cursor: {}
});
```
+ Il codice seguente termina una query.
```
db.adminCommand({killOp: 1, op: });
```
+ Utilizza il codice seguente per ottenere una visualizzazione aggregata dello stato del sistema.
```
db.adminCommand({aggregate: 1,
pipeline: [{$currentOp: {allUsers: true, idleConnections: true}},
{$group: {_id: {desc: "$desc", ns: "$ns", WaitState: "$WaitState"}, count: {$sum: 1}}}],
cursor: {}
});
```
# Raccolta dei rifiuti in Amazon DocumentDB
Amazon DocumentDB implementa un'architettura di database MVCC (Multi-version Concurrency Control) che crea nuove versioni di voci di documenti e indici per ogni operazione di aggiornamento. Questa architettura consente l'isolamento delle transazioni, impedendo che le modifiche di una transazione appaiano in un'altra.
**Topics**
+ [Comprendere la Garbage Collection in Amazon DocumentDB](#understanding-garbage-collection)
+ [Processo di raccolta dei rifiuti](#garbage-collection-process)
+ [Architettura di storage e storage esteso](#storage-architecture)
+ [Monitoraggio della raccolta dei rifiuti](#monitoring-garbage-collection)
+ [Esempio di output CollStats](#example-collstats-output)
+ [Domande frequenti](#garbage-collection-faq)
## Comprendere la Garbage Collection in Amazon DocumentDB
Garbage collection (GC) è un processo automatizzato in background che mantiene prestazioni e disponibilità di sistema ottimali in Amazon DocumentDB. Come molti database moderni, l'architettura MVCC di Amazon DocumentDB crea nuove versioni di documenti e indici con ogni aggiornamento. Ogni operazione di scrittura utilizza un ID MVCC univoco da un contatore finito. Questi IDs identificano a quale transazione appartiene la versione di un documento e se è stato eseguito il commit o il rollback. Nel tempo, queste vecchie versioni e il relativo MVCC IDs si accumulano e richiedono una pulizia per prevenire il degrado delle prestazioni.
### Funzioni di raccolta dei rifiuti
Garbage collector svolge tre funzioni essenziali:
+ **Recupera spazio di archiviazione**: rimuove le versioni obsolete di documenti e indici che non sono più necessarie per le query attive, liberando spazio per future operazioni di scrittura.
+ **Impedisce l'overflow dell'ID MVCC: previene l'overflow** dell'ID MVCC gestendo il contatore finito di MVCC. IDs Senza questa gestione, il contatore alla fine raggiungerebbe il limite, forzando il database a passare alla modalità temporanea di sola lettura fino al riciclo. IDs
+ **Mantiene le prestazioni delle query**: mantiene le prestazioni ottimali delle query eliminando le versioni obsolete dei documenti che altrimenti si accumulerebbero e rallenterebbero l'elaborazione delle query.
## Processo di raccolta dei rifiuti
Il processo GC funziona per raccolta e può avere più processi in esecuzione contemporaneamente su diverse raccolte. Il processo consiste in quattro fasi sequenziali:
1. **Identificazione**: il sistema identifica le versioni dei documenti e degli indici a cui non fanno più riferimento le transazioni o le query attive.
1. **Caricamento della memoria**: i vecchi documenti e le voci dell'indice vengono caricati in memoria se non sono già presenti.
1. **Eliminazione**: le versioni obsolete vengono eliminate definitivamente per recuperare spazio di archiviazione.
1. **Riciclaggio degli ID MVCC: il sistema ricicla** l'MVCC IDs delle versioni eliminate per nuove operazioni.
Quando Garbage Collection completa l'elaborazione delle vecchie versioni dei documenti, rimuove l'MVCC più vecchio dal sistema. IDs Questa pulizia è fondamentale per prevenire l'overflow degli ID MVCC riciclando MVCC e rendendoli disponibili per nuove IDs operazioni di scrittura nel cluster. Senza questo processo di riciclaggio, il sistema finirebbe per esaurire il contatore ID MVCC finito e passare allo stato di sola lettura.
### Pianificazione della raccolta dei rifiuti
La raccolta dei rifiuti viene eseguita automaticamente in background a intervalli periodici. La tempistica e la frequenza si regolano dinamicamente in base al carico del sistema, alle risorse disponibili, al volume di scrittura e ai livelli di consumo dell'ID MVCC. Durante un'elevata attività di scrittura, il processo GC viene eseguito più frequentemente per gestire l'aumento del numero di versioni dei documenti.
## Architettura di storage e storage esteso
Amazon DocumentDB utilizza una sofisticata architettura di storage che separa lo storage dei documenti in due segmenti distinti:
### Segmento di archiviazione di base
Il segmento di archiviazione di base contiene i dati e i metadati principali del documento. Questo segmento memorizza:
+ Contenuto del documento che rientra nelle dimensioni standard della pagina (8 KB).
+ Metadati del documento e informazioni sulla struttura.
+ Indici primari e relative voci.
+ Statistiche e configurazione a livello di raccolta.
### Segmento di archiviazione esteso
Il segmento di archiviazione estesa utilizza un archivio di oggetti documentale di grandi dimensioni specializzato progettato per gestire documenti che superano le dimensioni della pagina di archiviazione standard. Questo segmento offre:
+ **Gestione efficiente di documenti di grandi dimensioni**: i documenti che superano la soglia di archiviazione di base vengono spostati automaticamente nel segmento di archiviazione estesa.
+ **Layout di archiviazione ottimizzato**: il segmento utilizza un formato di archiviazione diverso ottimizzato per oggetti di grandi dimensioni, che riduce la frammentazione e migliora i modelli di accesso.
+ **Independent Garbage Collection**: il segmento di archiviazione estesa dispone di un proprio processo di raccolta dei rifiuti che può essere eseguito indipendentemente dalla pulizia dello storage di base.
+ **Accesso trasparente**: le applicazioni accedono senza problemi a documenti di grandi dimensioni senza bisogno di sapere quale segmento di archiviazione contiene i dati.
Il segmento di archiviazione esteso è particolarmente utile per:
+ Raccolte con documenti contenenti matrici incorporate di grandi dimensioni.
+ Documenti con ampie strutture annidate.
+ Raccolte che memorizzano dati binari o campi di testo di grandi dimensioni.
+ Applicazioni con documenti di dimensioni miste in cui alcuni documenti superano notevolmente le dimensioni medie.
## Monitoraggio della raccolta dei rifiuti
### Metriche a livello di cluster
**`AvailableMVCCIds`**
+ **Ubicazione** — Amazon CloudWatch
+ **Descrizione**: un contatore che mostra il numero di operazioni di scrittura rimanenti disponibili a partire da un limite massimo di 1,8 miliardi. Quando questo contatore raggiunge lo zero, il cluster entra in modalità di sola lettura fino a quando non IDs viene recuperato e riciclato. Il contatore diminuisce a ogni operazione di scrittura e aumenta man mano che la Garbage Collection ricicla il vecchio MVCC. IDs
+ **Raccomandazione**: imposta un allarme quando il valore scende al di sotto di 1,3 miliardi. Questo avviso precoce consente di adottare le misure consigliate discusse più avanti.
**`LongestActiveGCRuntime`**
+ **Ubicazione** — Amazon CloudWatch
+ **Descrizione**: 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.
+ **Raccomandazione**: confrontalo con i dati `gcRuntimeStats` storici per identificare comportamenti anomali di raccolta dei rifiuti, ad esempio tempi di esecuzione prolungati durante le eliminazioni in blocco.
### Metriche a livello di raccolta
**`MVCCIDStats: MVCCIdScale`**
+ **Posizione** — comando CollStats del database
+ **Descrizione**: misura l'età dell'ID MVCC su una scala da 0 a 1, dove 1 indica l'età massima prima che un cluster entri in uno stato di sola lettura. Utilizza questa metrica insieme `AvailableMVCCIds` per identificare le raccolte contenenti l'MVCC più vecchio IDs che stanno invecchiando il cluster.
+ **Raccomandazione**: mantieni i valori inferiori a 0,3 per ogni raccolta.
**`gcRuntimeStats`**
+ **Posizione** — comando CollStats del database
+ **Descrizione**: fornisce una cronologia di due mesi delle metriche relative alla raccolta dei rifiuti, tra cui esecuzioni totali, durata media e durata massima. Include solo le operazioni di raccolta dei rifiuti che durano più di cinque minuti per garantire statistiche significative.
**Importante**
`gcRuntimeStats`e `documentFragmentStats` la suddivisione delle metriche a livello di raccolta in `storageSegmentBase` e `storageSegmentExtended` sono disponibili solo per Amazon DocumentDB 8.0.
**`storageSizeStats`**
+ **Posizione** — comando CollStats del database
+ **Descrizione**: fornisce un'analisi dettagliata dell'utilizzo dello storage tra diversi segmenti di storage:
+ `storageSegmentBase`— Archiviazione utilizzata dal segmento di archiviazione di base per i documenti standard
+ `storageSegmentExtended`— Archiviazione utilizzata dal segmento di archiviazione esteso per documenti di grandi dimensioni
+ **Utilizzo**: consente di identificare le raccolte con uno spazio di archiviazione di documenti di grandi dimensioni e di comprendere i modelli di distribuzione dell'archiviazione.
**`unusedStorageSize`**(livello di raccolta)
+ **Posizione** — comando CollStats del database
+ **Descrizione**: stima lo spazio di archiviazione inutilizzato in una raccolta in base a statistiche campionate. Include lo spazio dei documenti eliminati e dei segmenti vuoti. La metrica fornisce sia i totali combinati che le suddivisioni per segmento:
+ Combinato e trasversale a tutti i segmenti di storage `unusedBytes` `unusedPercent`
+ `storageSegmentBase`— Spazio inutilizzato, in particolare nel segmento di archiviazione di base
+ `storageSegmentExtended`— Spazio inutilizzato, in particolare nel segmento di archiviazione esteso
**`documentFragmentStats`**
+ **Posizione** — comando CollStats del database
+ **Descrizione**: fornisce informazioni dettagliate sui frammenti di documenti e sui dati obsoleti all'interno delle raccolte. I frammenti di documento rappresentano le unità di archiviazione interne utilizzate dal motore di database e i frammenti morti indicano dati che non sono più accessibili ma non sono ancora stati recuperati. Questa metrica include:
+ `totalDocFragmentsCount`— Numero totale di frammenti di documento nella raccolta
+ `deadDocFragmentsCount`— Numero di frammenti contenenti dati morti (inaccessibili)
+ `deadDocFragmentsPercent`— Percentuale di frammenti che contengono dati non più validi
+ `deadDocFragmentBytes`— Stima dei byte consumati dai frammenti di documento non funzionanti
+ Suddivisione per segmento per e `storageSegmentBase` `storageSegmentExtended`
+ **Utilizzo**: monitora questa metrica per comprendere l'efficacia della raccolta dei rifiuti e identificare le raccolte che potrebbero trarre vantaggio dalle operazioni di manutenzione. Alte percentuali di frammenti morti indicano che la raccolta dei rifiuti potrebbe essere in ritardo o che la raccolta trarrebbe vantaggio dall'ottimizzazione.
### Metriche a livello di indice
**`unusedStorageSize`**(livello di indice)
+ **Posizione: comando** Database IndexStats
+ **Descrizione**: stima lo spazio di archiviazione inutilizzato in un indice in base a statistiche campionate. Include lo spazio occupato dalle voci di indice obsolete e dai segmenti vuoti.
+ **Raccomandazione**: utilizzate il `reIndex` comando per ricostruire gli indici senza tempi di inattività e recuperare lo spazio inutilizzato. Per maggiori dettagli, consulta Gestione degli indici.
## Esempio di output CollStats
L'esempio seguente mostra un `collStats` output tipico con metriche di raccolta e archiviazione dei rifiuti:
```
{
"ns" : "Mvcc_consumption_test_db.mvcc_test_collection",
"MVCCIdStats" : {
"MVCCIdScale" : 0.03
},
"gcRuntimeStats" : {
"numRuns" : 1,
"historicalAvgRuntime" : 3295,
"historicalMaxRuntime" : 3295,
"lastRuntime" : 3295,
"lastRuntimeStart" : ISODate("2025-06-24T08:47:14Z")
},
"documentFragmentStats" : {
"totalDocFragmentsCount" : 45000000,
"deadDocFragmentsCount" : 2250000,
"deadDocFragmentsPercent" : 5.0,
"deadDocFragmentBytes" : 98304000,
"storageSegmentBase" : {
"totalDocFragmentsCount" : 30000000,
"deadDocFragmentsCount" : 1500000,
"deadDocFragmentsPercent" : 5.0,
"deadDocFragmentBytes" : 65536000
},
"storageSegmentExtended" : {
"totalDocFragmentsCount" : 15000000,
"deadDocFragmentsCount" : 750000,
"deadDocFragmentsPercent" : 5.0,
"deadDocFragmentBytes" : 32768000
}
},
"collScans" : 14,
"count" : 30000000,
"size" : 1320000000,
"avgObjSize" : 44,
"storageSize" : 6461497344,
"storageSizeStats" : {
"storageSegmentBase" : 4307664896,
"storageSegmentExtended" : 2153832448
},
"capped" : false,
"nindexes" : 2,
"totalIndexSize" : 9649553408,
"indexSizes" : {
"_id_" : 1910661120,
"c_1" : 7738892288
},
"unusedStorageSize" : {
"unusedBytes" : 4201881600,
"unusedPercent" : 65.05,
"storageSegmentBase" : {
"unusedBytes" : 2801254400,
"unusedPercent" : 65.05
},
"storageSegmentExtended" : {
"unusedBytes" : 1400627200,
"unusedPercent" : 65.05
}
},
"cacheStats" : {
"collBlksHit" : 171659016,
"collBlksRead" : 754061,
"collHitRatio" : 99.5627,
"idxBlksHit" : 692563636,
"idxBlksRead" : 1177921,
"idxHitRatio" : 99.8303
},
"idxScans" : 41823984,
"opCounter" : {
"numDocsIns" : 0,
"numDocsUpd" : 20911992,
"numDocsDel" : 0
},
"lastReset" : "2025-06-24 05:57:08.219711+00",
"ok" : 1,
"operationTime" : Timestamp(1750968826, 1)
}
```
## Domande frequenti
### Come posso identificare se la raccolta dei rifiuti non funziona in modo efficiente?
Monitora questi segnali di avvertimento che indicano una raccolta dei rifiuti inefficiente:
+ **Eccessivo aumento della raccolta: `unusedStorageSize` metriche in** costante aumento durante le operazioni di scrittura o le eliminazioni di massa, specialmente con indici di grandi dimensioni.
+ **Alta percentuale di frammenti morti: mostra valori costantemente elevati (superiori al 10-15%**)`documentFragmentStats`. `deadDocFragmentsPercent`
+ **Latenza di interrogazione ridotta: maggiore latenza delle query** dovuta all'accumulo di documenti non funzionanti.
+ **Durata GC estesa**: le operazioni di raccolta dei rifiuti richiedono più tempo rispetto alle medie storiche. `gcRuntimeStats`
+ **Elaborazione GC elevata**: un `LongestActiveGCRuntime` valore elevato indica che il Garbage Collector non è in grado di tenere il passo con le richieste del sistema.
### La raccolta dei rifiuti influisce sulle prestazioni del mio database?
In condizioni normali, la raccolta dei rifiuti ha un impatto minimo sulle prestazioni. Tuttavia, quando la raccolta dei rifiuti è in ritardo, è possibile che si verifichino:
+ Aumento dei costi di archiviazione dovuti all'accumulo di documenti obsoleti.
+ Prestazioni di query più lente a causa di voci di indice obsolete.
+ Modalità temporanea di sola lettura se MVCC è esaurito. IDs
+ Maggiore utilizzo delle risorse durante le operazioni di raccolta intensive, specialmente su istanze più piccole.
+ Efficienza ridotta nelle operazioni su segmenti di archiviazione estesi per documenti di grandi dimensioni.
### Posso attivare manualmente la raccolta dei rifiuti?
No, la raccolta dei rifiuti in Amazon DocumentDB non può essere attivata manualmente. Il sistema gestisce automaticamente la raccolta dei rifiuti nell'ambito delle sue operazioni di manutenzione interne.
### Quali allarmi devo impostare come best practice operativa?
Ti consigliamo di configurare il monitoraggio sia a livello di cluster che di raccolta per garantire prestazioni ottimali del tuo sistema Amazon DocumentDB.
Per il monitoraggio a livello di cluster, inizia creando un CloudWatch allarme Amazon per la `AvailableMVCCIds` metrica con una soglia di 1,3 miliardi. In questo modo avrai il tempo sufficiente per agire prima che la metrica raggiunga lo zero, dopodiché il cluster entrerà in modalità di sola lettura. Tieni presente che questa metrica può variare in base ai tuoi modelli di utilizzo specifici: alcuni clienti la vedono scendere al di sotto di 1,3 miliardi per poi risalire oltre 1,5 miliardi una volta completata la raccolta dei rifiuti.
È anche importante monitorare la `LongestActiveGCRuntime` metrica tramite Amazon CloudWatch. Questa metrica, insieme a`gcRuntimeStats`, ti aiuta a capire l'efficienza della raccolta dei rifiuti in tutto il tuo sistema.
Per il monitoraggio a livello di raccolta, concentrati su queste metriche chiave:
+ `MVCCIdScale`— Attenzione ai valori crescenti che indicano che gli MVCC IDs stanno invecchiando e potrebbero richiedere attenzione.
+ `gcRuntimeStats`— Identifica i processi di raccolta dei rifiuti che richiedono tempi insolitamente lunghi o si estendono per più giorni.
+ `documentFragmentStats`— Monitora `deadDocFragmentsPercent` i valori: percentuali costantemente elevate (superiori al 10-15%) possono indicare che la raccolta dei rifiuti è in ritardo.
+ `storageSizeStats`e `unusedStorageSize` — Tieni traccia dei modelli di utilizzo dello storage e identifica le raccolte con una notevole quantità di spazio inutilizzato in entrambi i segmenti di archiviazione.
Le raccolte con operazioni di scrittura frequenti richiedono un'attenzione particolare, poiché generano più lavoro per il garbage collector. Ti consigliamo di controllare più frequentemente queste metriche per le raccolte con un'intensa attività di scrittura per garantire che Garbage Collection stia al passo con il tuo carico di lavoro.
Tieni presente che questi consigli di monitoraggio servono come punto di partenza. Man mano che acquisisci maggiore familiarità con il comportamento del sistema, potresti voler modificare queste soglie per adattarle meglio ai tuoi modelli e requisiti di utilizzo specifici.
### Cosa devo fare se il mio valore `AvailableMVCCIds` scende al di sotto di 1,3 miliardi?
Se la `AvailableMVCCIds` metrica scende al di sotto di 1,3 miliardi, ti consigliamo di agire immediatamente per impedire al cluster di passare alla modalità di sola lettura. Ti consigliamo innanzitutto di aumentare le dimensioni dell'istanza per fornire al Garbage Collector più risorse di elaborazione. Questa è la nostra raccomandazione principale in quanto consente all'applicazione di continuare le normali operazioni fornendo al garbage collector la potenza aggiuntiva di cui ha bisogno per recuperare il ritardo.
Se il solo ridimensionamento non migliora la situazione, consigliamo di prendere in considerazione una riduzione delle operazioni di scrittura. Utilizza la `MVCCIdScale` metrica per identificare quali raccolte specifiche contengono MVCC meno recenti IDs che richiedono attenzione. Inoltre, monitora `documentFragmentStats` per identificare le raccolte con percentuali elevate di frammenti morti che potrebbero contribuire all'inefficienza della raccolta dei rifiuti.
Una volta identificate queste raccolte, potrebbe essere necessario ridurre temporaneamente le operazioni di scrittura su di esse per consentire alla garbage collection di recuperare il ritardo. Durante il periodo di recupero, ti consigliamo di monitorare attentamente la `AvailableMVCCIds` metrica per assicurarti che le tue azioni abbiano l'effetto desiderato. Il cluster viene considerato integro una volta che il `AvailableMVCCIds` valore torna a 1,5 miliardi o superiore.
Ricorda che questi passaggi sono misure preventive per aiutare il sistema a riprendersi prima che raggiunga uno stato critico. Quanto prima si interviene dopo aver visto la metrica scendere al di sotto di 1,3 miliardi, tanto più è probabile che si eviti qualsiasi impatto sulle operazioni di scrittura.