Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Minimalkan overhead perencanaan
Seperti yang dibahas [Topik utama di Apache Spark](key-topics-apache-spark.md), driver Spark menghasilkan rencana eksekusi. Berdasarkan rencana itu, tugas ditugaskan ke pelaksana Spark untuk pemrosesan terdistribusi. Namun, driver Spark dapat menjadi hambatan jika ada sejumlah besar file kecil atau jika AWS Glue Data Catalog berisi sejumlah besar partisi. Untuk mengidentifikasi overhead perencanaan yang tinggi, nilai metrik berikut.
## CloudWatch metrik
Periksa **Pemanfaatan CPU** dan **Pemanfaatan Memori** untuk situasi berikut:
+ Spark driver **CPU Load** dan **Memory Utilization** dicatat sebagai tinggi. Biasanya, driver Spark tidak memproses data Anda, sehingga beban CPU dan pemanfaatan memori tidak melonjak. Namun, jika sumber data Amazon S3 memiliki terlalu banyak file kecil, mencantumkan semua objek S3 dan mengelola sejumlah besar tugas dapat menyebabkan pemanfaatan sumber daya menjadi tinggi.
+ Ada celah panjang sebelum pemrosesan dimulai di pelaksana Spark. Dalam contoh screenshot berikut, CPU Load Spark executor terlalu rendah hingga 10:57, meskipun pekerjaan dimulai pada 10:00. AWS Glue Ini menunjukkan bahwa driver Spark mungkin membutuhkan waktu lama untuk membuat rencana eksekusi. Dalam contoh ini, mengambil sejumlah besar partisi di Katalog Data dan mencantumkan sejumlah besar file kecil di driver Spark membutuhkan waktu lama.
![\[Grafik yang menunjukkan driver dan pelaksana.\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/tuning-aws-glue-for-apache-spark/images/cpu-load-2.png)
## Spark UI
Pada tab **Job** di UI Spark, Anda dapat melihat waktu yang **dikirimkan**. Dalam contoh berikut, pengemudi Spark memulai job0 pada 10:56:46, meskipun pekerjaan dimulai pada 10:00:00. AWS Glue
![\[""\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/tuning-aws-glue-for-apache-spark/images/jobs.png)
**Anda juga dapat melihat **Tugas (untuk semua tahapan): Sukses/Total waktu** pada tab Job.** Dalam hal ini, jumlah tugas dicatat sebagai`58100`. Seperti yang dijelaskan di bagian Amazon S3 dari halaman [tugas Parallelize, jumlah tugas](parallelize-tasks.md) kira-kira sesuai dengan jumlah objek S3. Ini berarti ada sekitar 58.100 objek di Amazon S3.
Untuk detail selengkapnya tentang pekerjaan dan timeline ini, tinjau tab **Stage**. Jika Anda mengamati kemacetan dengan driver Spark, pertimbangkan solusi berikut:
+ [Ketika Amazon S3 memiliki terlalu banyak file, pertimbangkan panduan tentang paralelisme berlebihan di bagian *Terlalu banyak partisi di halaman tugas Parallelize*.](parallelize-tasks.md)
+ [Ketika Amazon S3 memiliki terlalu banyak partisi, pertimbangkan panduan tentang partisi berlebihan di bagian partisi *Amazon S3 Terlalu banyak di halaman Kurangi jumlah pemindaian* data.](reduce-data-scan.md) Aktifkan [indeks AWS Glue partisi](https://docs.aws.amazon.com/glue/latest/dg/partition-indexes.html) jika ada banyak partisi untuk mengurangi latensi untuk mengambil metadata partisi dari Katalog Data. Untuk informasi selengkapnya, lihat [Meningkatkan kinerja kueri menggunakan indeks AWS Glue partisi](https://aws.amazon.com/blogs/big-data/improve-query-performance-using-aws-glue-partition-indexes/).
+ Ketika JDBC memiliki terlalu banyak partisi, turunkan nilainya. `hashpartition`
+ Ketika DynamoDB memiliki terlalu banyak partisi, turunkan nilainya. `dynamodb.splits`
+ Ketika pekerjaan streaming memiliki terlalu banyak partisi, turunkan jumlah pecahan.