

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

# Solucione de problemas de desempenho
<a name="performance-troubleshooting"></a>

Esta seção contém uma lista de sintomas que você pode verificar para diagnosticar e corrigir problemas de desempenho.

Se sua fonte de dados for um stream do Kinesis, os problemas de desempenho geralmente se apresentam como uma métrica alta ou crescente`millisbehindLatest`. Para outras fontes, você pode verificar uma métrica semelhante que representa o atraso na leitura da fonte.

## Entender o caminho dos dados
<a name="performance-troubleshooting-data"></a>

Ao investigar um problema de desempenho com seu aplicativo, considere todo o caminho que seus dados percorrem. Os seguintes componentes do aplicativo podem se tornar gargalos de desempenho e criar contrapressão se não forem projetados ou provisionados adequadamente:
+ **Fontes de dados e destinos:** garanta que os recursos externos com os quais seu aplicativo interage sejam adequadamente provisionados para o throughput que seu aplicativo experimentará.
+ **Dados do estado:** certifique-se de que seu aplicativo não interaja com o armazenamento do estado com muita frequência. 

  Você pode otimizar o serializador que seu aplicativo está usando. O serializador Kryo padrão pode lidar com qualquer tipo serializável, mas você pode usar um serializador com melhor desempenho se seu aplicativo armazenar dados apenas em tipos POJO. Para obter informações sobre serializadores do Apache Flink, consulte [ Tipos de dados e serialização](                 https://nightlies.apache.org/flink/flink-docs-release-1.18/docs/dev/datastream/fault-tolerance/serialization/types_serialization/) na documentação do Apache Flink.
+ **Operadores:** garanta que a lógica de negócios implementada por seus operadores não seja muito complicada ou que você não esteja criando ou usando recursos com cada registro processado. Além disso, certifique-se de que seu aplicativo não esteja criando janelas deslizantes ou giratórias com muita frequência.

## Soluções para resolver problemas de desempenho
<a name="performance-troubleshooting-solutions"></a>

Esta seção contém possíveis soluções para problemas de desempenho.

**Topics**
+ [CloudWatch níveis de monitoramento](#performance-troubleshooting-solutions-monitoring)
+ [Métrica da CPU do aplicativo](#performance-troubleshooting-solutions-cpu)
+ [Paralelismo do aplicativo](#performance-troubleshooting-solutions-parallelism)
+ [Registro em log de aplicações](#performance-troubleshooting-solutions-logging)
+ [Paralelismo do operador](#performance-troubleshooting-solutions-operators)
+ [Lógica do aplicativo](#performance-troubleshooting-solutions-logic)
+ [Memória do aplicativo](#performance-troubleshooting-solutions-memory)

### CloudWatch níveis de monitoramento
<a name="performance-troubleshooting-solutions-monitoring"></a>

Verifique se os níveis de CloudWatch monitoramento não estão definidos para uma configuração muito detalhada.

A `Debug` configuração do nível de log de monitoramento gera uma grande quantidade de tráfego, o que pode criar contrapressão. Você só deve usá-lo enquanto estiver investigando ativamente os problemas com o aplicativo. 

Se seu aplicativo tiver uma `Parallelism` configuração alta, o uso do ` Parallelism` Nível de Métricas de Monitoramento também gerará uma grande quantidade de tráfego que pode causar contrapressão. Use esse nível de métrica somente quando `Parallelism` seu aplicativo estiver baixo ou ao investigar problemas com o aplicativo.

Para obter mais informações, consulte [Controle os níveis de monitoramento do aplicativo](cloudwatch-logs.md#cloudwatch_levels).

### Métrica da CPU do aplicativo
<a name="performance-troubleshooting-solutions-cpu"></a>

Verifique a `CPU` métrica do aplicativo. Se essa métrica estiver acima de 75 por cento, você pode permitir que o aplicativo aloque mais recursos para si mesmo ativando o ajuste de escala automático.

Se o ajuste de escala automático estiver ativado, o aplicativo aloca mais recursos se o uso da CPU for superior a 75% por 15 minutos. Para obter mais informações sobre escalonamento, consulte a seção [Gerenciar a escalabilidade de forma adequada](performance-improving.md#performance-improving-scaling) a seguir, e [Implemente a escalabilidade de aplicativos](how-scaling.md).

**nota**  
Um aplicativo só será escalado automaticamente em resposta ao uso da CPU. O aplicativo não será escalado automaticamente em resposta a outras métricas do sistema, como`heapMemoryUtilization`. Se seu aplicativo tiver um alto nível de uso de outras métricas, aumente o paralelismo do aplicativo manualmente.

### Paralelismo do aplicativo
<a name="performance-troubleshooting-solutions-parallelism"></a>

Aumente o paralelismo do aplicativo. Você atualiza o paralelismo do aplicativo usando o `ParallelismConfigurationUpdate` parâmetro da ação. [UpdateApplication](https://docs.aws.amazon.com/managed-flink/latest/apiv2/API_UpdateApplication.html)

 O máximo KPUs para um aplicativo é 64 por padrão e pode ser aumentado solicitando um aumento de limite.

Também é importante atribuir paralelismo a cada operador com base em seu workload, em vez de aumentar apenas o paralelismo do aplicativo. Veja [Paralelismo do operador](#performance-troubleshooting-solutions-operators) a seguir.

### Registro em log de aplicações
<a name="performance-troubleshooting-solutions-logging"></a>

Verifique se o aplicativo está registrando uma entrada para cada log que está sendo processado. Gravar uma entrada de log para cada registro nos momentos em que o aplicativo tem alto throughput causará graves gargalos no processamento de dados. Para verificar essa condição, consulte seus logs em busca de entradas de logs que seu aplicativo grava com cada registro que ele processa. Para mais informações sobre a leitura de logs de aplicativo, consulte [Analise registros com o CloudWatch Logs Insights](cloudwatch-logs-reading.md).

### Paralelismo do operador
<a name="performance-troubleshooting-solutions-operators"></a>

Verifique se o workload do seu aplicativo está distribuído uniformemente entre os processos de trabalho.

Para obter informações sobre como ajustar o workload dos operadores do seu aplicativo, consulte[Escalonamento operador](performance-improving.md#performance-improving-scaling-op).

### Lógica do aplicativo
<a name="performance-troubleshooting-solutions-logic"></a>

Examine a lógica do seu aplicativo em busca de operações ineficientes ou sem desempenho, como acessar uma dependência externa (como um banco de dados ou um serviço web), acessar o estado do aplicativo etc. Uma dependência externa também pode prejudicar o desempenho se não tiver desempenho ou não for acessível de forma confiável, o que pode fazer com que a dependência externa retorne erros. `HTTP 500` 

Se seu aplicativo usa uma dependência externa para enriquecer ou processar dados recebidos, considere usar E/S assíncrona em vez disso. Para obter mais informações, consulte [ E/S assíncrona](https://ci.apache.org/projects/flink/flink-docs-stable/dev/stream/operators/asyncio.html) na [Documentação do Apache Flink](https://ci.apache.org/projects/flink/flink-docs-release-1.8/).

### Memória do aplicativo
<a name="performance-troubleshooting-solutions-memory"></a>

Verifique se há vazamentos de recursos em seu aplicativo. Se seu aplicativo não estiver descartando adequadamente os encadeamentos ou a memória, você poderá ver `millisbehindLatest`, `CheckpointSize` e `CheckpointDuration` o aumento ou o aumento gradual da métrica. Essa condição também pode levar a falhas no gerenciador de tarefas ou no gerenciador de tarefas.