

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

# Diagnosi della limitazione (della larghezza di banda della rete)
<a name="throttling-diagnosing-workflow"></a>

Quando la tua applicazione subisce una limitazione, DynamoDB fornisce informazioni dettagliate sulle eccezioni e CloudWatch metriche mirate per aiutarti a diagnosticare questi eventi.

In questa sezione viene presentato un approccio sistematico alla comprensione degli eventi di limitazione (della larghezza di banda della rete) nelle applicazioni DynamoDB. Mostra come interpretare le eccezioni di limitazione, correlarle con le CloudWatch metriche per ottenere informazioni più approfondite e capire quali modifiche ridurrebbero il throttling nelle applicazioni DynamoDB.

## Funzionamento delle eccezioni di limitazione (della larghezza di banda della rete)
<a name="throttling-exceptions"></a>

Quando DynamoDB limita sottopone a limitazione (della larghezza di banda della rete) una richiesta, restituisce eccezioni specifiche con informazioni diagnostiche dettagliate. Ad esempio, in Java, queste includono `ProvisionedThroughputExceededException`, `RequestLimitExceeded` o `ThrottlingException`.

Ogni eccezione include `ThrottlingReasons` una raccolta di dati `ThrottlingReason` singoli contenenti due campi chiave per aiutare a identificare e comprendere la limitazione (della larghezza di banda della rete):
+ **Un motivo**: un campo concatenato che segue il formato `<ResourceType><OperationType><LimitType>`
+ **Un ARN della risorsa**: il nome della risorsa Amazon (ARN) della tabella o dell’indice interessati

Il campo del motivo segue un modello coerente che aiuta a capire esattamente cosa sta succedendo:
+ **ResourceType**(Cosa viene limitato): oppure `Table` `Index`
+ **OperationType**(Che tipo di operazione): o `Read` `Write`
+ **LimitType**(Perché si è verificata la limitazione):
  + `KeyRangeThroughputExceeded`: si verifica quando una partizione specifica che supporta la tabella o l’indice ha utilizzato una capacità di lettura o scrittura oltre i limiti di throughput interni per partizione.
  + `ProvisionedThroughputExceeded`: si verifica su una tabella con provisioning o su un indice secondario globale quando il tasso di consumo di lettura o scrittura ha superato la quantità allocata.
  + `AccountLimitExceeded`: si verifica in una tabella o in un indice on demand quando il tasso di consumo di lettura o scrittura ha superato il tasso di consumo massimo per una tabella e i relativi indici impostato a livello di account. È possibile richiedere un aumento di questa quota.
  + `MaxOnDemandThroughputExceeded`: si verifica su una tabella o un indice on demand quando il tasso di consumo di lettura o scrittura ha superato il tasso di consumo massimo fornito dall’utente configurato per la tabella o l’indice. È possibile aumentare in prima persona questo valore a qualsiasi valore fino al limite dell’account o impostarlo su –1 per indicare che non ci sono limiti forniti dall’utente.

L’ARN della risorsa identifica esattamente quale tabella o quale indice sono sottoposti a limitazione (della larghezza di banda della rete):
+ Per le tabelle: `arn:aws:dynamodb:[region]:[account-id]:table/[table-name]`
+ Per gli indici: `arn:aws:dynamodb:[region]:[account-id]:table/[table-name]/index/[index-name]`

Esempi di motivi di limitazione (della larghezza di banda della rete) completa:
+ `TableReadProvisionedThroughputExceeded`
+ `IndexWriteAccountLimitExceeded`

In questo modo è possibile identificare esattamente quale risorsa viene sottoposta a limitazione (della larghezza di banda della rete), che tipo di operazione l’ha causata e perché si è verificata la limitazione.

### Eccezioni di esempio
<a name="throttling-exceptions-examples"></a>

#### Esempio 1: superamento della capacità allocata su un GSI
<a name="throttling-exceptions-example1"></a>

```
{
    "ThrottlingReasons": [
        {
            "reason": "IndexWriteProvisionedThroughputExceeded",
            "resource": "arn:aws:dynamodb:us-west-2:123456789012:table/CustomerOrders/index/OrderDateIndex"
        }
    ],
    "awsErrorDetails": {
        "errorCode": "ProvisionedThroughputExceeded",
        "errorMessage": "The level of configured provisioned throughput for the index was exceeded",
        "serviceName": "DynamoDB",
        "sdkHttpResponse": {
            "statusText": "Bad Request",
            "statusCode": 400
        }
    }
}
```

In questo esempio, l’applicazione riceve una `ProvisionedThroughputExceededException` con il motivo `IndexWriteProvisionedThroughputExceeded`. Alle scritture su `OrderDateIndex` viene applicata una limitazione (della larghezza di banda della rete) perché l’utilizzo di scrittura ha superato la capacità di scrittura allocata configurata del GSI.

#### Esempio 2: superamento del throughput massimo on demand
<a name="throttling-exceptions-example2"></a>

```
{
    "ThrottlingReasons": [
        {
            "reason": "TableReadMaxOnDemandThroughputExceeded",
            "resource": "arn:aws:dynamodb:us-east-1:123456789012:table/UserSessions"
        }
    ],
    "awsErrorDetails": {
        "errorMessage": "Throughput exceeds the maximum OnDemandThroughput configured on table or index",
        "errorCode": "ThrottlingException",
        "serviceName": "DynamoDB",
        "sdkHttpResponse": {
            "statusText": "Bad Request",
            "statusCode": 400
        }
    }
}
```

In questo esempio, le letture dalla tabella `UserSessions` subiscono una limitazione (della larghezza di banda della rete) perché superano il limite massimo di throughput on demand configurato nella tabella.

## Framework di diagnosi della limitazione (della larghezza di banda della rete) di DynamoDB
<a name="throttling-diagnosing"></a>

Quando l’applicazione riscontra una limitazione (della larghezza di banda della rete), segui questa procedura per diagnosticare e risolvere il problema.

### Fase 1: analizzare i dettagli di `ThrottlingReason`
<a name="analyze-exception"></a>

1. Controlla il campo **motivo** per identificare il motivo specifico della limitazione (della larghezza di banda della rete). Il motivo descrive in dettaglio il tipo di risorsa sottoposta a limitazione (della larghezza di banda della rete) (tabella o indice), il tipo di operazione che ha causato l’evento di limitazione (lettura o scrittura) e il tipo di limite superato (partizione, throughput allocato, limite dell’account).

1. Controlla il campo **resourceArn** per identificare quale risorsa (tabella o GSI) subisce la limitazione (della larghezza di banda della rete).

1. Utilizza queste informazioni combinate per comprendere il contesto completo del problema della limitazione (della larghezza di banda della rete).

   Ad esempio, si consideri questo scenario in cui compare la seguente eccezione `ProvisionedThroughputExceededException` con motivo di limitazione (della larghezza di banda della rete) `TableWriteKeyRangeThroughputExceeded`. Il resourceARN interessato è `arn:aws:dynamodb:us-west-2:123456789012:table/CustomerOrders`.

   Questa combinazione informa che le operazioni di scrittura sulla tabella `CustomerOrders` sono sottoposte a limitazione (della larghezza di banda della rete) e la limitazione si verifica a livello di partizione (non a livello di tabella, che verrebbe visualizzato come `TableWriteProvisionedThroughputExceeded`). La causa principale è che è stata superata la capacità di throughput massima per un valore o un intervallo specifico della chiave di partizione, il che indica un problema di partizione calda.

   La comprensione di questa relazione tra gli elementi di eccezione consente di implementare la strategia di mitigazione appropriata, in questo caso, risolvere il problema della partizione calda anziché aumentare la capacità complessiva allocata alla tabella.

### Fase 2 - CloudWatch Identifica e analizza i parametri correlati
<a name="analyze-cloudwatch-metrics"></a>

1. **Identifica le tue metriche:** ogni motivo di limitazione in DynamoDB corrisponde direttamente a CloudWatch metriche specifiche che puoi monitorare per tracciare e analizzare gli eventi di throttling. È possibile derivare sistematicamente i nomi delle metriche appropriati dal motivo della limitazione. CloudWatch 

1. Abbina il motivo della limitazione alle metriche corrispondenti utilizzando questa tabella di riferimento: CloudWatch   
**Motivi di limitazione completi e riferimento alle metriche CloudWatch**    
<a name="throttling-reasons-metrics"></a>[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/amazondynamodb/latest/developerguide/throttling-diagnosing-workflow.html)

   Ad esempio, se hai ricevuto`IndexWriteProvisionedThroughputExceeded`, come minimo, dovresti monitorare la `WriteProvisionedThroughputThrottleEvents` CloudWatch metrica per l'indice specifico identificato in. `ResourceArn`

1. Monitora queste metriche CloudWatch per comprendere la frequenza e la tempistica degli eventi di limitazione, distinguere tra limitazione in lettura e scrittura, identificare gli schemi temporali in cui la limitazione aumenta e tenere traccia delle tendenze di utilizzo della capacità.

   DynamoDB pubblica metriche dettagliate per ogni tabella e indice secondario globale. Le metriche (`ReadThrottleEvents`,`WriteThrottleEvents` e `ThrottledRequests`) aggregano tutti gli eventi di limitazione (della larghezza di banda della rete) della tabella e dei relativi indici.

### Fase 3 - Identifica i tasti limitati e le alte percentuali di accesso utilizzando Contributor Insights (per la limitazione relativa alle partizioni) CloudWatch
<a name="throttling-diagnosing-cci"></a>

Se hai identificato problemi relativi alle partizioni nella Fase 1 (ad esempio `KeyRangeThroughputExceeded` errori), CloudWatch Contributor Insights for DynamoDB può aiutarti a diagnosticare quali chiavi specifiche generano il traffico e registrano eventi di limitazione nella tabella o nell'indice. 

1. Abilita CloudWatch Contributor Insights per la tua tabella o indice con limitazioni in base al tuo. `ResourceARN` 

   È possibile scegliere la modalità *Chiavi con limitazione (della larghezza di banda della rete)* per concentrarsi sulle chiavi con maggiore limitazione. Questa modalità è ideale per il monitoraggio continuo in quanto elabora gli eventi solo quando si verifica una limitazione (della larghezza di banda della rete). In alternativa, la modalità *Chiavi con accessi e limitazione (della larghezza di banda della rete)* consente di osservare i modelli nelle chiavi a cui si accede più spesso.

1. Analizza i report per identificare i modelli problematici. Cerca chiavi con tassi di accesso o di limitazione (della larghezza di banda della rete) sproporzionatamente elevati e metti in correlazione i modelli di limitazione e traffico. Puoi creare dashboard integrate combinando grafici di Contributor Insights e metriche DynamoDB. CloudWatch 

Per informazioni dettagliate sull'attivazione e l'utilizzo di CloudWatch Contributor Insights, consulta [Uso di CloudWatch Contributor Insights per DynamoDB](contributorinsights.md).

### Fase 4: determinare la soluzione appropriata
<a name="throttling-diagnosing-remediate"></a>

Dopo aver diagnosticato la causa specifica della limitazione (della larghezza di banda della rete), implementa la soluzione consigliata in base al contesto specifico. La soluzione appropriata dipende da diversi fattori, tra cui lo scenario di limitazione (della larghezza di banda della rete), la modalità di capacità della tabella, le decisioni di progettazione delle chiavi e delle tabelle, i modelli di accesso e l’efficienza delle query, la configurazione degli indici globali e secondari, l’architettura generale del sistema e i punti di integrazione.

Per soluzioni dettagliate per affrontare gli scenari di limitazione (della larghezza di banda della rete) specifici, consulta la sezione [Guida alla risoluzione della limitazione (della larghezza di banda della rete) in DynamoDB](troubleshooting-throttling-diagnostics.md). Questa risorsa fornisce strategie di correzione mirate personalizzate in base al particolare motivo di limitazione (della larghezza di banda della rete) e alla configurazione della modalità di capacità.

### Fase 5: monitorare i progressi
<a name="throttling-diagnosing-monitor"></a>

1. Tieni traccia delle CloudWatch metriche che corrispondono al tuo scenario di limitazione.

1. L’efficacia delle strategie di mitigazione può essere verificata tramite la diminuzione degli eventi di questo tipo.