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á.
# Minimizar a sobrecarga de planejamento
Conforme analisado em [Principais tópicos do Apache Spark](key-topics-apache-spark.md), o driver do Spark gera o plano de execução. Com base nesse plano, as tarefas são atribuídas ao executor do Spark para processamento distribuído. No entanto, o driver do Spark pode se tornar um gargalo se houver um grande número de arquivos pequenos ou se o AWS Glue Data Catalog contiver um grande número de partições. Para identificar a alta sobrecarga de planejamento, avalie as métricas a seguir.
## CloudWatch métricas
Verifique a **Carga da CPU** e a **Utilização da memória** nas seguintes situações:
+ A **Carga da CPU** e a **Utilização da memória** do driver do Spark estão registradas como altas. Normalmente, o driver do Spark não processa seus dados, portanto, a carga da CPU e a utilização da memória não têm picos. No entanto, se a fonte de dados do Amazon S3 tiver muitos arquivos pequenos, listar todos os objetos do S3 e gerenciar um grande número de tarefas pode fazer com que a utilização dos recursos seja alta.
+ Há uma grande lacuna antes do início do processamento no executor do Spark. No exemplo de captura de tela a seguir, a carga da CPU do executor do Spark está muito baixa até 10:57, mesmo que o trabalho tenha começado às 10:00. AWS Glue Isso indica que o driver do Spark pode estar demorando muito para gerar um plano de execução. Neste exemplo, recuperar o grande número de partições no Catálogo de Dados e listar o grande número de arquivos pequenos no driver do Spark está demorando muito.
![\[Grafo mostrando o driver e executores.\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/tuning-aws-glue-for-apache-spark/images/cpu-load-2.png)
## Interface do usuário do Spark
Na guia **Trabalho** na interface do usuário do Spark, você pode ver o horário de **Envio**. No exemplo a seguir, o driver do Spark iniciou o job0 às 10:56:46, embora o trabalho tenha começado às 10:00:00. AWS Glue
![\[""\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/tuning-aws-glue-for-apache-spark/images/jobs.png)
Você também pode ver o horário das **Tarefas (para todas as etapas): Com êxito/Total** na guia **Trabalho**. Nesse caso, o número de tarefas é registrado como `58100`. Conforme explicado na seção do Amazon S3 da página [Paralelizar tarefas](parallelize-tasks.md), o número de tarefas corresponde aproximadamente ao número de objetos do S3. Isso significa que há cerca de 58.100 objetos no Amazon S3.
Para obter mais detalhes sobre esse trabalho e o cronograma, revise a guia **Etapa**. Se você observar um gargalo com o driver do Spark, considere as seguintes soluções:
+ Quando o Amazon S3 tem muitos arquivos, considere a orientação sobre paralelismo excessivo na seção *Muitas partições* da página [Paralelizar tarefas](parallelize-tasks.md).
+ Quando o Amazon S3 tem muitas partições, considere a orientação sobre particionamento excessivo na seção *Muitas partições do Amazon S3* da página [Reduzir a quantidade de dados verificados](reduce-data-scan.md). Habilite os [índices de partição do AWS Glue](https://docs.aws.amazon.com/glue/latest/dg/partition-indexes.html) se houver muitas partições para reduzir a latência na recuperação de metadados de partições do Catálogo de Dados. Para obter mais informações, consulte [Melhorar o desempenho da consulta usando índices de AWS Glue partição](https://aws.amazon.com/blogs/big-data/improve-query-performance-using-aws-glue-partition-indexes/).
+ Quando o JDBC tiver muitas partições, diminua o valor de `hashpartition`.
+ Quando o DynamoDB tiver muitas partições, diminua o valor de `dynamodb.splits`.
+ Quando os trabalhos de streaming tiverem muitas partições, diminua o número de fragmentos.