

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

# Risolvi i problemi relativi alle prestazioni
<a name="performance-troubleshooting"></a>

Questa sezione contiene un elenco di caratteristiche la cui verifica permette di diagnosticare e risolvere i problemi relativi alle prestazioni.

Se l'origine dati è un flusso Kinesis, i problemi di prestazioni in genere si presentano nella forma di una metrica `millisbehindLatest` elevata o in crescita. Per altre fonti, è consigliabile controllare una metrica simile che rappresenta il ritardo nella lettura dalla fonte.

## Comprendi il percorso dei dati
<a name="performance-troubleshooting-data"></a>

Quando analizzi un problema relativo alle prestazioni dell’applicazione, considera l'intero percorso compiuto dai dati. I seguenti componenti dell'applicazione possono ridurre l’efficacia delle prestazioni e creare una congestione, se non sono progettati o predisposti correttamente:
+ **Fonti e destinazioni dei dati:** assicurati che le risorse esterne con cui interagisce l'applicazione siano adeguatamente fornite per la velocità effettiva dell'applicazione.
+ **Dati sullo stato:** è fondamentale assicurarsi che l'applicazione non interagisca in maniera troppo frequente con l’archivio degli stati precedenti. 

  È possibile ottimizzare il serializzatore utilizzato dall'applicazione. Il serializzatore Kryo predefinito può gestire qualsiasi tipo serializzabile, tuttavia è possibile utilizzare un serializzatore più performante se l'applicazione memorizza solo dati in tipi POJO. Per informazioni sui serializzatori Apache Flink, consulta [Tipi di dati e](                 https://nightlies.apache.org/flink/flink-docs-release-1.18/docs/dev/datastream/fault-tolerance/serialization/types_serialization/) serializzazione nella documentazione di Apache Flink.
+ **Operatori:** la logica di business implementata dagli operatori non deve essere eccessivamente complicata; è meglio evitare, inoltre, che ogni record elaborato crei o utilizzi risorse. Assicurati inoltre che l'applicazione non crei finestre scorrevoli o a cascata con troppa frequenza.

## Soluzioni per la risoluzione dei problemi
<a name="performance-troubleshooting-solutions"></a>

Questa sezione contiene potenziali soluzioni ai problemi relativi alle prestazioni.

**Topics**
+ [CloudWatch livelli di monitoraggio](#performance-troubleshooting-solutions-monitoring)
+ [Metrica della CPU dell'applicazione](#performance-troubleshooting-solutions-cpu)
+ [Parallelismo delle applicazioni](#performance-troubleshooting-solutions-parallelism)
+ [Registrazione dell'applicazione](#performance-troubleshooting-solutions-logging)
+ [Parallelismo dell'operatore](#performance-troubleshooting-solutions-operators)
+ [Logica dell'applicazione](#performance-troubleshooting-solutions-logic)
+ [Memoria dell'applicazione](#performance-troubleshooting-solutions-memory)

### CloudWatch livelli di monitoraggio
<a name="performance-troubleshooting-solutions-monitoring"></a>

Verificare che i livelli di CloudWatch monitoraggio non siano impostati su un'impostazione troppo dettagliata.

L'impostazione `Debug` Monitoraggio del livello dei log genera una grande quantità di traffico, che può creare una congestione. È consigliabile utilizzarla unicamente quando si esaminano in maniera attiva i problemi relativi all'applicazione. 

Se l'applicazione ha un'impostazione `Parallelism` elevata, l'utilizzo del ` Parallelism`livello delle metriche di monitoraggio genererà analogamente una grande quantità di traffico, che può portare a una congestione. È consigliabile utilizzare questo livello di metriche solo quando `Parallelism` per l'applicazione è a un livello ridotto o durante l'analisi di problemi relativi all'applicazione.

Per ulteriori informazioni, consulta [Controlla i livelli di monitoraggio delle applicazioni](cloudwatch-logs.md#cloudwatch_levels).

### Metrica della CPU dell'applicazione
<a name="performance-troubleshooting-solutions-cpu"></a>

Controlla la metrica `CPU` dell'applicazione. Se è superiore al 75%, è possibile consentire all'applicazione di allocare una quantità superiore di risorse a sé stessa, abilitando il dimensionamento automatico.

Quando il dimensionamento automatico è abilitato e l'utilizzo della CPU è superiore al 75% per 15 minuti, l'applicazione alloca una quantità superiore di risorse. Per ulteriori informazioni sul dimensionamento è possibile consultare le sezioni [Gestire correttamente il dimensionamento](performance-improving.md#performance-improving-scaling) e [Implementa la scalabilità delle applicazioni](how-scaling.md).

**Nota**  
Le applicazioni vengono dimensionate automaticamente solo in risposta all'utilizzo della CPU. L'applicazione non si ridimensiona automaticamente in risposta ad altre metriche di sistema, come `heapMemoryUtilization`. Se il livello di utilizzo dell'applicazione per altre metriche è elevato, è consigliabile aumentarne manualmente il parallelismo.

### Parallelismo delle applicazioni
<a name="performance-troubleshooting-solutions-parallelism"></a>

Consente di aumentare il parallelismo dell'applicazione. Il parallelismo dell'applicazione viene aggiornato utilizzando il `ParallelismConfigurationUpdate` parametro dell'azione. [UpdateApplication](https://docs.aws.amazon.com/managed-flink/latest/apiv2/API_UpdateApplication.html)

 Il massimo KPUs per un'applicazione è 64 per impostazione predefinita e può essere aumentato richiedendo un aumento del limite.

È importante inoltre assegnare il parallelismo a ciascun operatore in base al relativo carico di lavoro, anziché limitarsi ad aumentare il parallelismo dell’applicazione. Leggi [Parallelismo dell'operatore](#performance-troubleshooting-solutions-operators) quanto segue.

### Registrazione dell'applicazione
<a name="performance-troubleshooting-solutions-logging"></a>

Controlla se l'applicazione registra un log per ogni record elaborato. La creazione di un log per ogni record provocherà gravi rallentamenti nell'elaborazione dei dati durante i periodi in cui l'applicazione presenta una velocità di trasmissione effettiva elevata. Per verificare questa condizione, interroga i log alla ricerca delle voci di registro create dall'applicazione per ogni nuovo record che elabora. Per ulteriori informazioni relative all’analisi dei log delle applicazioni, consulta [Analizza i log con CloudWatch Logs Insights](cloudwatch-logs-reading.md).

### Parallelismo dell'operatore
<a name="performance-troubleshooting-solutions-operators"></a>

Verifica che il carico di lavoro dell'applicazione sia distribuito in modo uniforme tra i processi di lavoro.

Per informazioni sull’ottimizzazione del carico di lavoro degli operatori dell'applicazione, consulta. [Dimensionamento degli operatori](performance-improving.md#performance-improving-scaling-op)

### Logica dell'applicazione
<a name="performance-troubleshooting-solutions-logic"></a>

Esamina la logica dell'applicazione per individuare eventuali azioni poco efficienti o dalle prestazioni ridotte, come l'accesso a una dipendenza esterna (un database o un servizio web, per esempio), l'accesso allo stato dell'applicazione, ecc. Una dipendenza esterna può inoltre limitare le prestazioni, se non è efficiente o non è accessibile in modo affidabile, il che può causare errori `HTTP 500` ricorrenti nella restituzione della dipendenza esterna. 

L’impiego dell'IO asincrono può rivelarsi utile se l’applicazione si avvale di una dipendenza esterna per l’arricchimento o l’elaborazione dei dati in entrata. Per ulteriori informazioni, consulta [Async I/O](https://ci.apache.org/projects/flink/flink-docs-stable/dev/stream/operators/asyncio.html) nella [documentazione di Apache Flink](https://ci.apache.org/projects/flink/flink-docs-release-1.8/).

### Memoria dell'applicazione
<a name="performance-troubleshooting-solutions-memory"></a>

Verifica l’assenza di dispersione delle risorse all’interno dell'applicazione. Se l'applicazione non elimina correttamente i thread o la memoria, è possibile che si verifichi un picco o un aumento graduale dei parametri `millisbehindLatest`, `CheckpointSize` e `CheckpointDuration`. Tale situazione può causare, inoltre, errori nel task manager o nel job manager.