Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Pemantauan dan debugging Job
Anda dapat mengumpulkan metrik tentang AWS Glue pekerjaan dan memvisualisasikannya di CloudWatch konsol AWS Glue Amazon dan Amazon untuk mengidentifikasi dan memperbaiki masalah. Membuat profil tugas AWS Glue memerlukan langkah-langkah berikut:
1. Aktifkan metrik:
1. Mengaktifkan opsi **Metrik Tugas** dalam definisi tugas. Anda dapat mengaktifkan pemrofilan di konsol AWS Glue atau sebagai sebuah parameter untuk tugas. Untuk informasi selengkapnya, lihat [Mendefinisikan properti pekerjaan untuk pekerjaan Spark](add-job.md#create-job) atau [Menggunakan parameter pekerjaan dalam pekerjaan AWS Glue](aws-glue-programming-etl-glue-arguments.md).
1. Aktifkan opsi **metrik AWS Glue Observabilitas** dalam definisi pekerjaan. Anda dapat mengaktifkan Observabilitas di AWS Glue konsol atau sebagai parameter untuk pekerjaan. Untuk mengetahui informasi selengkapnya, lihat [Pemantauan dengan metrik AWS Glue Observabilitas](monitor-observability.md).
1. Mengonfirmasi bahwa skrip tugas menginisialisasi sebuah `GlueContext`. Sebagai contoh, potongan skrip berikut menginisialisasi `GlueContext` dan menunjukkan di mana kode yang diprofilkan ditempatkan dalam skrip tersebut. Format umum ini digunakan dalam skenario debugging yang mengikuti.
```
import sys
from awsglue.transforms import *
from awsglue.utils import getResolvedOptions
from pyspark.context import SparkContext
from awsglue.context import GlueContext
from awsglue.job import Job
import time
## @params: [JOB_NAME]
args = getResolvedOptions(sys.argv, ['JOB_NAME'])
sc = SparkContext()
glueContext = GlueContext(sc)
spark = glueContext.spark_session
job = Job(glueContext)
job.init(args['JOB_NAME'], args)
...
...
code-to-profile
...
...
job.commit()
```
1. Jalankan tugas.
1. Visualisasikan metrik:
1. Visualisasikan metrik pekerjaan di AWS Glue konsol dan identifikasi metrik abnormal untuk driver atau pelaksana.
1. Periksa metrik observabilitas di halaman pemantauan Job run, halaman detail menjalankan pekerjaan, atau di Amazon. CloudWatch Untuk informasi selengkapnya, lihat [Pemantauan dengan metrik AWS Glue Observabilitas](monitor-observability.md).
1. Persempit akar masalah dengan menggunakan metrik yang diidentifikasi.
1. Opsional, mengonfirmasi akar masalah menggunakan pengaliran log dari driver atau pelaksana tugas yang diidentifikasi.
**Gunakan kasus untuk AWS Glue metrik observabilitas**
+ [Debugging pengecualian OOM dan kelainan pekerjaan](monitor-profile-debug-oom-abnormalities.md)
+ [Mendebug tahapan yang menuntut dan tugas yang menyimpang](monitor-profile-debug-straggler.md)
+ [Memantau kemajuan beberapa pekerjaan](monitor-debug-multiple.md)
+ [Pemantauan perencanaan kapasitas DPU](monitor-debug-capacity.md)
+ [Menggunakan AWS Glue Observabilitas untuk memantau pemanfaatan sumber daya untuk mengurangi biaya](https://aws.amazon.com/blogs/big-data/enhance-monitoring-and-debugging-for-aws-glue-jobs-using-new-job-observability-metrics)
# Debugging pengecualian OOM dan kelainan pekerjaan
Anda dapat men-debug pengecualian out-of-memory (OOM) dan kelainan pekerjaan di. AWS Glue Bagian berikut menjelaskan skenario untuk debugging out-of-memory pengecualian driver Apache Spark atau pelaksana Spark.
+ [Mendebug pengecualian OOM driver](#monitor-profile-debug-oom-driver)
+ [Mendebug pengecualian OOM eksekutor](#monitor-profile-debug-oom-executor)
## Mendebug pengecualian OOM driver
Dalam skenario ini, sebuah tugas Spark membaca sejumlah besar file dalam ukuran kecil dari Amazon Simple Storage Service (Amazon S3). Ia mengkonversi file tersebut ke format Apache Parquet dan kemudian menulisnya ke Amazon S3. Driver Spark sedang kehabisan memori. Data input Amazon S3 memiliki lebih dari 1 juta file dalam partisi Amazon S3 yang berbeda.
Kode profilannya adalah sebagai berikut:
```
data = spark.read.format("json").option("inferSchema", False).load("s3://input_path")
data.write.format("parquet").save(output_path)
```
### Visualisasikan metrik yang diprofilkan di konsol AWS Glue
Grafik berikut menunjukkan penggunaan memori dalam satuan persentase untuk driver dan pelaksana. Penggunaan ini diplot sebagai satu titik data yang dirata-ratakan atas nilai-nilai yang dilaporkan di menit terakhir. Anda dapat melihat di profil memori dari tugas bahwa [memori driver](monitoring-awsglue-with-cloudwatch-metrics.md#glue.driver.jvm.heap.usage) melewati ambang batas aman penggunaan 50 persen dengan cepat. Di sisi lain, [penggunaan memori rata-rata](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.jvm.heap.usage) di semua pelaksana masih kurang dari 4 persen. Hal ini jelas menunjukkan kelainan yang terjadi pada pelaksana eksekusi driver dalam tugas Spark ini.
![\[Penggunaan memori dalam satuan persentase untuk driver dan pelaksana.\]](http://docs.aws.amazon.com/id_id/glue/latest/dg/images/monitor-debug-oom-memoryprofile.png)
Eksekusi tugas segera gagal, dan kesalahan berikut muncul di tab **Riwayat** pada Konsol AWS Glue: Perintah Gagal dengan Kode Keluar 1. String kesalahan ini berarti bahwa tugas gagal karena adanya sebuah kesalahan sistemik—yang dalam hal ini adalah bahwa driver kehabisan memori.
![\[Pesan kesalahan yang ditampilkan pada konsol AWS Glue.\]](http://docs.aws.amazon.com/id_id/glue/latest/dg/images/monitor-debug-oom-errorstring.png)
Di konsol, pilih tautan **Kesalahan log** pada tab **Sejarah** untuk mengonfirmasi temuan tentang driver OOM dari CloudWatch Log. Cari "**Error**" di log kesalahan tugas untuk mengonfirmasi bahwa hal itu memang pengecualian OOM yang membuat tugas gagal:
```
# java.lang.OutOfMemoryError: Java heap space
# -XX:OnOutOfMemoryError="kill -9 %p"
# Executing /bin/sh -c "kill -9 12039"...
```
Pada tab **Riwayat** untuk tugas, pilih **Log**. Anda dapat menemukan jejak eksekusi driver berikut di CloudWatch Log di awal pekerjaan. Driver Spark mencoba untuk mencantumkan semua file di semua direktori, membangun sebuah `InMemoryFileIndex`, dan meluncurkan satu tugas setiap file. Hal ini pada gilirannya akan mengakibatkan driver Spark harus mempertahankan sejumlah besar status di memori untuk melacak semua tugas. Ia meng-cache daftar lengkap dari sejumlah besar file untuk indeks dalam memori, yang mengakibatkan driver mengalami OOM.
### Perbaiki pemrosesan beberapa file menggunakan pengelompokan
Anda dapat memperbaiki pemrosesan beberapa file dengan menggunakan fitur *pengelompokan dalam grup* di AWS Glue. Pengelompokan dalam grup secara otomatis diaktifkan ketika Anda menggunakan bingkai dinamis dan ketika set data masukan memiliki sejumlah besar file (lebih dari 50.000). Pengelompokan dalam grup memungkinkan Anda untuk menggabungkan beberapa file bersama-sama ke dalam sebuah grup, dan memungkinkan tugas untuk memproses seluruh grup tersebut, alih-alih satu file. Akibatnya, driver Spark menyimpan jauh lebih sedikit status di memori untuk melacak lebih sedikit tugas. Untuk informasi lebih lanjut tentang pengaktifan pengelompokan data dalam grup secara manual, lihat [Membaca file input dalam kelompok yang lebih besar](grouping-input-files.md).
Untuk memeriksa profil memori tugas AWS Glue, lakukan pemrofilan pada kode berikut dengan pengelompokan grup diaktifkan:
```
df = glueContext.create_dynamic_frame_from_options("s3", {'paths': ["s3://input_path"], "recurse":True, 'groupFiles': 'inPartition'}, format="json")
datasink = glueContext.write_dynamic_frame.from_options(frame = df, connection_type = "s3", connection_options = {"path": output_path}, format = "parquet", transformation_ctx = "datasink")
```
Anda dapat memantau profil memori dan pergerakan data ETL di profil tugas AWS Glue.
Driver berjalan di bawah ambang batas penggunaan memori 50 persen di sepanjang durasi tugas AWS Glue. Pelaksana mengalirkan data dari Amazon S3, memprosesnya, dan menuliskan data tersebut ke Amazon S3. Akibatnya, mereka menggunakan memori kurang dari 5 persen pada setiap titik waktu.
![\[Profil memori yang menunjukkan masalah tersebut telah diperbaiki.\]](http://docs.aws.amazon.com/id_id/glue/latest/dg/images/monitor-debug-oom-memoryprofile-fixed.png)
Profil pergerakan data di bawah ini menunjukkan jumlah byte Amazon S3 yang [di-baca](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.s3.filesystem.read_bytes) dan [di-tulis](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.s3.filesystem.write_bytes) pada menit terakhir oleh semua pelaksana saat tugas berlangsung. Keduanya mengikuti pola yang sama karena data dialirkan di semua pelaksana. Tugas tersebut menyelesaikan proses satu juta file dalam waktu kurang dari tiga jam.
![\[Profil pergerakan data yang menunjukkan masalah tersebut telah diperbaiki.\]](http://docs.aws.amazon.com/id_id/glue/latest/dg/images/monitor-debug-oom-etlmovement.png)
## Mendebug pengecualian OOM eksekutor
Dalam skenario ini, Anda dapat belajar bagaimana melakukan debug pada pengecualian OOM yang dapat terjadi dalam pelaksana Apache Spark. Kode berikut menggunakan pembaca Spark MySQL untuk membaca tabel besar yang mempunyai sekitar 34 juta baris ke dataframe Spark. Ia kemudian tulis tabel tersebut ke Amazon S3 dalam format Parquet. Anda dapat memberikan properti koneksi dan menggunakan konfigurasi Spark default untuk membaca tabel tersebut.
```
val connectionProperties = new Properties()
connectionProperties.put("user", user)
connectionProperties.put("password", password)
connectionProperties.put("Driver", "com.mysql.jdbc.Driver")
val sparkSession = glueContext.sparkSession
val dfSpark = sparkSession.read.jdbc(url, tableName, connectionProperties)
dfSpark.write.format("parquet").save(output_path)
```
### Visualisasikan metrik yang diprofilkan di konsol AWS Glue
Jika kemiringan grafik penggunaan memori positif dan melewati 50 persen, maka jika tugas gagal sebelum metrik berikutnya dipancarkan, maka kelelahan memori menjadi kandidat yang tepat sebagai penyebabnya. Grafik berikut menunjukkan bahwa dalam satu menit eksekusi, [penggunaan memori rata-rata](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.jvm.heap.usage) di semua pelaksana melonjak dengan cepat di atas 50 persen. Penggunaan mencapai hingga 92 persen dan kontainer yang menjalankan pelaksana dihentikan oleh Apache Hadoop YARN.
![\[Penggunaan memori rata-rata di seluruh pelaksana.\]](http://docs.aws.amazon.com/id_id/glue/latest/dg/images/monitor-debug-oom-2-memoryprofile.png)
Seperti yang ditunjukkan pada grafik berikut, selalu ada satu [pelaksana tunggal](monitoring-awsglue-with-cloudwatch-metrics.md#glue.driver.ExecutorAllocationManager.executors.numberAllExecutors) yang berjalan sampai tugas gagal. Hal ini karena pelaksana baru diluncurkan untuk menggantikan pelaksana yang dihentikan. Pembacaan sumber data JDBC tidak diparalelisasi secara default karena akan membutuhkan pemartisian tabel pada kolom dan membuka beberapa koneksi. Akibatnya, hanya satu pelaksana yang membaca dalam tabel yang lengkap secara berurutan.
![\[Eksekusi tugas menunjukkan satu pelaksana tunggal berjalan sampai tugas gagal.\]](http://docs.aws.amazon.com/id_id/glue/latest/dg/images/monitor-debug-oom-2-execution.png)
Sebagaimana ditunjukkan dalam grafik berikut, Spark mencoba untuk meluncurkan tugas baru empat kali sebelum gagal tugas. Anda dapat melihat [profil memori](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.jvm.heap.used) dari tiga pelaksana. Setiap pelaksana dengan cepat menggunakan semua memorinya. Pelaksana keempat kehabisan memori, dan tugas gagal. Akibatnya, metriknya tidak langsung dilaporkan.
![\[Profil memori dari pelaksana.\]](http://docs.aws.amazon.com/id_id/glue/latest/dg/images/monitor-debug-oom-2-exec-memprofile.png)
Anda dapat mengonfirmasi dari string kesalahan pada konsol AWS Glue bahwa tugas gagal karena pengecualian OOM, seperti yang ditunjukkan dalam gambar berikut.
![\[Pesan kesalahan yang ditampilkan pada konsol AWS Glue.\]](http://docs.aws.amazon.com/id_id/glue/latest/dg/images/monitor-debug-oom-2-errorstring.png)
**Log keluaran Job:** Untuk mengonfirmasi lebih lanjut temuan Anda tentang pengecualian OOM eksekutor, lihat CloudWatch Log. Saat Anda mencari **Error**, Anda menemukan empat pelaksana yang dihentikan di sekitar jendela waktu yang sama seperti yang ditunjukkan pada dasbor metrik. Semua diakhiri oleh YARN karena mereka melebihi batas memori mereka.
Pelaksana 1
```
18/06/13 16:54:29 WARN YarnAllocator: Container killed by YARN for exceeding memory limits. 5.5 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
18/06/13 16:54:29 WARN YarnSchedulerBackend$YarnSchedulerEndpoint: Container killed by YARN for exceeding memory limits. 5.5 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
18/06/13 16:54:29 ERROR YarnClusterScheduler: Lost executor 1 on ip-10-1-2-175.ec2.internal: Container killed by YARN for exceeding memory limits. 5.5 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
18/06/13 16:54:29 WARN TaskSetManager: Lost task 0.0 in stage 0.0 (TID 0, ip-10-1-2-175.ec2.internal, executor 1): ExecutorLostFailure (executor 1 exited caused by one of the running tasks) Reason: Container killed by YARN for exceeding memory limits. 5.5 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
```
Pelaksana 2
```
18/06/13 16:55:35 WARN YarnAllocator: Container killed by YARN for exceeding memory limits. 5.8 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
18/06/13 16:55:35 WARN YarnSchedulerBackend$YarnSchedulerEndpoint: Container killed by YARN for exceeding memory limits. 5.8 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
18/06/13 16:55:35 ERROR YarnClusterScheduler: Lost executor 2 on ip-10-1-2-16.ec2.internal: Container killed by YARN for exceeding memory limits. 5.8 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
18/06/13 16:55:35 WARN TaskSetManager: Lost task 0.1 in stage 0.0 (TID 1, ip-10-1-2-16.ec2.internal, executor 2): ExecutorLostFailure (executor 2 exited caused by one of the running tasks) Reason: Container killed by YARN for exceeding memory limits. 5.8 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
```
Pelaksana 3
```
18/06/13 16:56:37 WARN YarnAllocator: Container killed by YARN for exceeding memory limits. 5.8 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
18/06/13 16:56:37 WARN YarnSchedulerBackend$YarnSchedulerEndpoint: Container killed by YARN for exceeding memory limits. 5.8 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
18/06/13 16:56:37 ERROR YarnClusterScheduler: Lost executor 3 on ip-10-1-2-189.ec2.internal: Container killed by YARN for exceeding memory limits. 5.8 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
18/06/13 16:56:37 WARN TaskSetManager: Lost task 0.2 in stage 0.0 (TID 2, ip-10-1-2-189.ec2.internal, executor 3): ExecutorLostFailure (executor 3 exited caused by one of the running tasks) Reason: Container killed by YARN for exceeding memory limits. 5.8 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
```
Pelaksana 4
```
18/06/13 16:57:18 WARN YarnAllocator: Container killed by YARN for exceeding memory limits. 5.5 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
18/06/13 16:57:18 WARN YarnSchedulerBackend$YarnSchedulerEndpoint: Container killed by YARN for exceeding memory limits. 5.5 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
18/06/13 16:57:18 ERROR YarnClusterScheduler: Lost executor 4 on ip-10-1-2-96.ec2.internal: Container killed by YARN for exceeding memory limits. 5.5 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
18/06/13 16:57:18 WARN TaskSetManager: Lost task 0.3 in stage 0.0 (TID 3, ip-10-1-2-96.ec2.internal, executor 4): ExecutorLostFailure (executor 4 exited caused by one of the running tasks) Reason: Container killed by YARN for exceeding memory limits. 5.5 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
```
### Perbaiki pengaturan ukuran ambil menggunakan frame AWS Glue dinamis
Pelaksana kehabisan memori saat membaca tabel JDBC karena konfigurasi default untuk ukuran pengambilan JDBC Spark adalah nol. Ini berarti bahwa driver JDBC pada pelaksana Spark mencoba untuk mengambil 34 juta baris dari basis data bersama-sama dan meng-cache mereka, meskipun pengaliran Spark melalui baris-baris tersebut, sekali dalam satu waktu. Dengan Spark, Anda dapat menghindari skenario ini dengan menetapkan parameter ukuran pengambilan ke nilai default non-nol.
Anda juga dapat memperbaiki masalah ini dengan menggunakan bingkai dinamis AWS Glue sebagai gantinya. Secara default, bingkai dinamis menggunakan ukuran pengambilan sebesar 1.000 baris yang merupakan nilai yang biasanya cukup. Akibatnya, pelaksana tidak mengambil lebih dari 7 persen dari total memorinya. Tugas AWS Glue selesai dalam waktu kurang dari dua menit dengan hanya satu pelaksana tunggal. Selain menggunakan bingkai dinamis AWS Glue merupakan pendekatan yang direkomendasikan, ia juga memungkinkan kita untuk mengatur ukuran pengambilan dengan menggunakan properti `fetchsize` Apache Spark. Lihat [Spark SQL, DataFrames dan Panduan Datasets](https://spark.apache.org/docs/2.2.0/sql-programming-guide.html#jdbc-to-other-databases).
```
val (url, database, tableName) = {
("jdbc_url", "db_name", "table_name")
}
val source = glueContext.getSource(format, sourceJson)
val df = source.getDynamicFrame
glueContext.write_dynamic_frame.from_options(frame = df, connection_type = "s3", connection_options = {"path": output_path}, format = "parquet", transformation_ctx = "datasink")
```
**Metrik profilan normal:** [Memori pelaksana](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.jvm.heap.usage) dengan bingkai dinamis AWS Glue tidak pernah melebihi ambang batas aman, seperti yang ditunjukkan pada gambar berikut. Ia mengalirkan dalam baris-baris dari basis data dan meng-cache hanya 1.000 baris dalam driver JDBC pada setiap titik waktu. Pengecualian kehabisan memori tidak terjadi.
![\[Konsol AWS Glue menunjukkan memori pelaksana di bawah ambang batas yang aman.\]](http://docs.aws.amazon.com/id_id/glue/latest/dg/images/monitor-debug-oom-2-memoryprofile-fixed.png)
# Mendebug tahapan yang menuntut dan tugas yang menyimpang
Anda dapat menggunakan pemrofilan tugas AWS Glue untuk mengidentifikasi tahapan yang menuntut dan tugas dengan performa buruk dalam tugas extract, transform, and load (ETL) Anda. Sebuah tugas dengan performa buruk memakan waktu lebih lama dari tugas-tugas lainnya dalam tahap sebuah tugas AWS Glue. Akibatnya, tahapan tersebut membutuhkan waktu lebih lama untuk selesai, yang juga menunda total waktu eksekusi tugas.
## Menggabungkan file input kecil menjadi file output yang lebih besar
Sebuah tugas dengan performa buruk dapat terjadi ketika ada distribusi pekerjaan yang tidak seragam di seluruh tugas yang berbeda, atau adanya data condong yang mengakibatkan satu tugas memproses lebih banyak data.
Anda dapat melakukan pemrofilan pada kode berikut—pola umum di Apache Spark—untuk menggabungkan sejumlah besar file kecil ke dalam file output yang lebih besar. Untuk contoh ini, set data inputnya adalah file JSON Gzip terkompresi sebesar 32 GB. Set data output mempunyai file JSON tidak terkompresi kira-kira sebesar 190 GB.
Kode profilannya adalah sebagai berikut:
```
datasource0 = spark.read.format("json").load("s3://input_path")
df = datasource0.coalesce(1)
df.write.format("json").save(output_path)
```
### Visualisasikan metrik yang diprofilkan di konsol AWS Glue
Anda dapat melakukan pemrofilan pada tugas Anda untuk memeriksa empat rangkaian metrik yang berbeda:
+ Pergerakan data ETL
+ Data yang diacak di seluruh pelaksana
+ Eksekusi tugas
+ Profil memori
**Pergerakan data ETL**: Dalam profil **Pergerakan data ETL**, byte [di-baca](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.s3.filesystem.read_bytes) cukup cepat oleh semua pelaksana di tahap pertama yang selesai dalam waktu enam menit pertama. Namun, total waktu eksekusi tugas sekitar satu jam, sebagian besar terdiri dari eksekusi [tulis](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.s3.filesystem.write_bytes) data.
![\[Grafik yang menunjukkan profil Pergerakan Data ETL.\]](http://docs.aws.amazon.com/id_id/glue/latest/dg/images/monitor-debug-straggler-1.png)
**Data yang diacak di seluruh pelaksana:** Jumlah byte yang [di-baca](monitoring-awsglue-with-cloudwatch-metrics.md#glue.driver.aggregate.shuffleLocalBytesRead) dan [di-tulis](monitoring-awsglue-with-cloudwatch-metrics.md#glue.driver.aggregate.shuffleBytesWritten) selama pengacakan juga menunjukkan lonjakan sebelum Tahap 2 berakhir, seperti yang ditunjukkan oleh metrik **Eksekusi Tugas** dan **Pengacakan Data**. Setelah pengacakan data dilakukan di semua pelaksana, baca dan tulis melanjutkan dari pelaksana nomor 3 saja.
![\[Metrik untuk data yang diacak di seluruh pelaksana.\]](http://docs.aws.amazon.com/id_id/glue/latest/dg/images/monitor-debug-straggler-2.png)
**Eksekusi Tugas:** Seperti ditunjukkan pada grafik di bawah ini, semua pelaksana lainnya menganggur dan akhirnya dilepaskan pada waktu 10:09. Pada saat itu, jumlah total pelaksana menurun menjadi hanya satu saja. Hal ini jelas menunjukkan bahwa pelaksana nomor 3 terdiri dari tugas dengan performa buruk yang mengambil waktu eksekusi paling lama dan memberikan kontribusi untuk sebagian besar waktu eksekusi tugas.
![\[Metrik eksekusi untuk pelaksana aktif.\]](http://docs.aws.amazon.com/id_id/glue/latest/dg/images/monitor-debug-straggler-3.png)
**Profil memori:** Setelah dua tahap pertama, hanya [pelaksana nomor 3](monitoring-awsglue-with-cloudwatch-metrics.md#glue.executorId.jvm.heap.used) yang secara aktif menggunakan memori untuk memproses data. Pelaksana yang tersisa hanya menganggur atau telah dilepaskan tak lama setelah dua tahap pertama selesai.
![\[Metrik untuk profil memori setelah dua tahapan pertama.\]](http://docs.aws.amazon.com/id_id/glue/latest/dg/images/monitor-debug-straggler-4.png)
### Perbaiki pelaksana yang tersesat menggunakan pengelompokan
Anda dapat menghindari terjadinya pelaksana dengan performa buruk dengan menggunakan fitur *pengelompokan dalam grup* di AWS Glue. Gunakan pengelompokan dalam grup untuk mendistribusikan data secara seragam di semua pelaksana dan menyatukan file-file ke dalam file yang lebih besar dengan menggunakan semua pelaksana yang tersedia pada klaster. Untuk informasi selengkapnya, lihat [Membaca file input dalam kelompok yang lebih besar](grouping-input-files.md).
Untuk memeriksa pergerakan data ETL di tugas AWS Glue, lakukan pemrofilan pada kode berikut dengan pengelompokan grup yang diaktifkan:
```
df = glueContext.create_dynamic_frame_from_options("s3", {'paths': ["s3://input_path"], "recurse":True, 'groupFiles': 'inPartition'}, format="json")
datasink = glueContext.write_dynamic_frame.from_options(frame = df, connection_type = "s3", connection_options = {"path": output_path}, format = "json", transformation_ctx = "datasink4")
```
**Pergerakan data ETL:** Data tulis sekarang dialirkan secara paralel dengan data baca di sepanjang waktu eksekusi tugas. Akibatnya, tugas selesai dalam delapan menit—jauh lebih cepat dari sebelumnya.
![\[Pergerakan data ETL yang menunjukkan masalah tersebut telah diperbaiki.\]](http://docs.aws.amazon.com/id_id/glue/latest/dg/images/monitor-debug-straggler-5.png)
**Data yang diacak di seluruh pelaksana:** Karena file input digabungkan selama baca menggunakan fitur pengelompokan dalam grup, tidak ada pengacakan data yang mahal setelah pembacaan data.
![\[Metrik pengacakan data yang menunjukkan masalah telah diperbaiki.\]](http://docs.aws.amazon.com/id_id/glue/latest/dg/images/monitor-debug-straggler-6.png)
**Eksekusi tugas:** Metrik eksekusi tugas menunjukkan bahwa jumlah pelaksana aktif yang menjalankan dan memproses data masih tetap cukup konstan. Tidak ada performa buruk yang terjadi dalam tugas itu. Semua pelaksana aktif dan tidak dilepaskan sampai tugas selesai. Karena tidak ada pengacakan menengah pada data di seluruh pelaksana, maka hanya ada satu tahap dalam tugas tersebut.
![\[Metrik untuk widget Eksekusi Tugas menunjukkan bahwa tidak ada perkerjaan dengan performa buruk dalam tugas tersebut.\]](http://docs.aws.amazon.com/id_id/glue/latest/dg/images/monitor-debug-straggler-7.png)
**Profil memori:** Metrik menunjukkan [konsumsi memori aktif](monitoring-awsglue-with-cloudwatch-metrics.md#glue.executorId.jvm.heap.used) di semua pelaksana—mengonfirmasi kembali bahwa ada aktivitas di semua pelaksana. Karena data dialirkan dan ditulis secara paralel, maka total jejak memori dari semua pelaksana kira-kira seragam dan jauh di bawah ambang batas aman untuk semua pelaksana.
![\[Metrik profil memori menunjukkan konsumsi memori aktif di semua pelaksana.\]](http://docs.aws.amazon.com/id_id/glue/latest/dg/images/monitor-debug-straggler-8.png)
# Memantau kemajuan beberapa pekerjaan
Anda dapat membuat profil beberapa AWS Glue pekerjaan bersama-sama dan memantau aliran data di antara mereka. Ini adalah sebuah pola alur kerja yang umum, dan memerlukan pemantauan untuk kemajuan tugas individu, backlog pemrosesan data, pemrosesan ulang data, dan bookmark tugas.
**Topics**
+ [Kode diprofilkan](#monitor-debug-multiple-profile)
+ [Visualisasikan metrik yang diprofilkan di konsol AWS Glue](#monitor-debug-multiple-visualize)
+ [Perbaiki pemrosesan file](#monitor-debug-multiple-fix)
## Kode diprofilkan
Dalam alur kerja ini, Anda memiliki dua tugas: Tugas Input dan Tugas Output. Tugas Input dijadwalkan untuk berjalan setiap 30 menit dengan menggunakan pemicu periodik. Tugas Output dijadwalkan untuk berjalan setelah setiap eksekusi Tugas Input yang berhasil. Tugas-tugas terjadwal ini dikendalikan dengan menggunakan pemicu tugas.
![\[Tangkapan layar konsol yang menunjukkan pemicu tugas yang mengendalikan penjadwalan tugas Input dan Output.\]](http://docs.aws.amazon.com/id_id/glue/latest/dg/images/monitor-debug-multiple-1.png)
**Tugas Input**: Tugas ini membaca data dari lokasi Amazon Simple Storage Service (Amazon S3), mengubahnya menggunakan `ApplyMapping`, dan menuliskannya ke lokasi Amazon S3 yang bertahap. Kode berikut adalah kode profilan untuk tugas Input:
```
datasource0 = glueContext.create_dynamic_frame.from_options(connection_type="s3", connection_options = {"paths": ["s3://input_path"], "useS3ListImplementation":True,"recurse":True}, format="json")
applymapping1 = ApplyMapping.apply(frame = datasource0, mappings = [map_spec])
datasink2 = glueContext.write_dynamic_frame.from_options(frame = applymapping1, connection_type = "s3", connection_options = {"path": staging_path, "compression": "gzip"}, format = "json")
```
**Tugas Output**: Tugas ini membaca output dari tugas Input dari lokasi pentahapan di Amazon S3, melakukan transformasi lagi padanya, dan menuliskannya ke tujuan:
```
datasource0 = glueContext.create_dynamic_frame.from_options(connection_type="s3", connection_options = {"paths": [staging_path], "useS3ListImplementation":True,"recurse":True}, format="json")
applymapping1 = ApplyMapping.apply(frame = datasource0, mappings = [map_spec])
datasink2 = glueContext.write_dynamic_frame.from_options(frame = applymapping1, connection_type = "s3", connection_options = {"path": output_path}, format = "json")
```
## Visualisasikan metrik yang diprofilkan di konsol AWS Glue
Dasbor berikut melapiskan metrik tertulis byte Amazon S3 dari tugas Input ke metrik pembacaan byte Amazon S3 pada lini waktu yang sama untuk tugas Output. Lini waktu tersebut menunjukkan eksekusi tugas yang berbeda dari tugas Input dan Output. Tugas Input (ditampilkan dalam warna merah) dimulai setiap 30 menit. Tugas Output (ditampilkan dalam warna coklat) dimulai pada saat Tugas Input selesai, dengan Konkurensi Maksimal 1.
![\[Grafik yang menampilkan data yang dibaca dan ditulis.\]](http://docs.aws.amazon.com/id_id/glue/latest/dg/images/monitor-debug-multiple-4.png)
Dalam contoh ini, [bookmark tugas](https://docs.aws.amazon.com/glue/latest/dg/monitor-continuations.html) tidak diaktifkan. Tidak ada konteks transformasi yang digunakan untuk mengaktifkan bookmark tugas dalam kode skrip tersebut.
**Riwayat Tugas**: Tugas Input dan Output menjalani beberapa eksekusi, seperti yang ditunjukkan pada tab **Riwayat**, mulai dari 12:00 siang.
Tugas Input pada konsol AWS Glue terlihat seperti ini:
![\[Tangkapan layar konsol yang menampilkan tab Riwayat tugas Input.\]](http://docs.aws.amazon.com/id_id/glue/latest/dg/images/monitor-debug-multiple-2.png)
Gambar berikut menunjukkan tugas Output:
![\[Tangkapan layar konsol yang menampilkan tab Riwayat tugas Output.\]](http://docs.aws.amazon.com/id_id/glue/latest/dg/images/monitor-debug-multiple-3.png)
**Eksekusi tugas pertama**: Seperti yang ditunjukkan dalam grafik Byte Data yang Di-baca dan Di-tulis di bawah ini, eksekusi tugas pertama dari tugas Input dan Output antara jam 12:00 dan 12:30 menunjukkan sekitar area yang sama di bawah kurva. Area-area tersebut mewakili byte Amazon S3 yang ditulis oleh tugas Input dan byte Amazon S3 yang dibaca oleh tugas Output. Data ini juga dikonfirmasi oleh rasio byte Amazon S3 yang ditulis (dijumlahkan lebih dari 30 menit – frekuensi pemicu tugas untuk tugas Input). Titik data untuk rasio untuk eksekusi tugas Input yang dimulai pada 12:00 siang juga 1.
Grafik berikut menunjukkan rasio pengaliran data di semua eksekusi tugas:
![\[Grafik yang menampilkan rasio pengaliran data: byte yang ditulis dan byte dibaca.\]](http://docs.aws.amazon.com/id_id/glue/latest/dg/images/monitor-debug-multiple-5.png)
**Eksekusi tugas kedua**: Dalam eksekusi tugas kedua, ada perbedaan yang jelas dalam jumlah byte yang dibaca oleh tugas Output dibandingkan dengan jumlah byte yang ditulis oleh tugas Input. (Bandingkan area di bawah kurva di dua eksekusi tugas untuk tugas Output, atau bandingkan area dalam eksekusi tugas kedua dari tugas Input dan Output.) Rasio byte yang dibaca dan ditulis menunjukkan bahwa Tugas Output membaca sekitar 2,5x data yang ditulis oleh tugas Input dalam rentang kedua 30 menit dari jam 12:30 hingga 13:00. Hal ini karena Tugas Output memproses kembali output eksekusi tugas pertama dari tugas Input karena bookmark tugas tidak diaktifkan. Rasio di atas 1 menunjukkan bahwa ada backlog data tambahan yang diproses oleh tugas Output.
**Eksekusi tugas ketiga**: Tugas Input cukup konsisten dalam hal jumlah byte yang ditulis (lihat area di bawah kurva merah). Namun, eksekusi tugas ketiga dari tugas Input berjalan lebih lama dari yang diharapkan (lihat ekor panjang kurva merah). Akibatnya, eksekusi tugas ketiga dari tugas Output dimulai terlambat. Eksekusi tugas ketiga hanya memproses sebagian kecil dari data yang terakumulasi di lokasi pentahapan di sisa 30 menit antara pukul 13:00 dan 13:30. Rasio aliran byte menunjukkan bahwa ia hanya memproses 0,83 data yang ditulis oleh eksekusi tugas ketiga dari tugas Input (lihat rasio di pukul 13:00).
**Tumpang tindih tugas Input dan Output**: Eksekusi tugas keempat dari tugas Input dimulai pada pukul 13:30 sesuai jadwal, sebelum eksekusi tugas ketiga dari tugas Output selesai. Ada tumpang tindih parsial antara dua eksekusi tugas ini. Namun demikian, eksekusi tugas ketiga dari tugas Output menangkap hanya file yang terdaftar di lokasi pentahapan Amazon S3 ketika dimulai sekitar pukul 13:17. Hal ini terdiri dari semua output data dari eksekusi tugas pertama dari tugas Input. Rasio aktual pada pukul 13:30 adalah sekitar 2.75. Eksekusi tugas ketiga dari tugas Output memproses sekitar 2.75x data yang ditulis oleh eksekusi tugas keempat dari tugas Input pada pukul 13:30 sampai 14:00.
Seperti yang ditunjukkan gambar ini, tugas Output mengolah ulang data dari lokasi pentahapan dari semua eksekusi tugas sebelumnya dari tugas Input. Akibatnya, eksekusi tugas keempat untuk tugas Output menjadi eksekusi tugas terpanjang dan tumpang tindih dengan seluruh eksekusi tugas kelima dari Input tugas.
## Perbaiki pemrosesan file
Anda harus memastikan bahwa tugas Output memproses hanya file yang belum diproses oleh eksekusi tugas sebelumnya dari tugas Output. Untuk melakukan ini, aktifkan bookmark tugas dan atur konteks transformasi dalam tugas Output, sebagai berikut:
```
datasource0 = glueContext.create_dynamic_frame.from_options(connection_type="s3", connection_options = {"paths": [staging_path], "useS3ListImplementation":True,"recurse":True}, format="json", transformation_ctx = "bookmark_ctx")
```
Dengan bookmark tugas yang diaktifkan, tugas Output tidak akan memproses ulang data di lokasi pentahapan dari semua eksekusi tugas sebelumnya dari tugas Input. Pada gambar berikut, menunjukkan data yang dibaca dan ditulis, area yang ada di bawah kurva coklat cukup konsisten dan mirip dengan kurva merah.
![\[Grafik yang menampilkan data yang dibaca dan ditulis sebagai garis merah dan coklat.\]](http://docs.aws.amazon.com/id_id/glue/latest/dg/images/monitor-debug-multiple-6.png)
Rasio aliran byte juga kira-kira masih tetap mendekati 1 karena tidak ada data tambahan yang diproses.
![\[Grafik yang menampilkan rasio pengaliran data: byte yang ditulis dan byte dibaca\]](http://docs.aws.amazon.com/id_id/glue/latest/dg/images/monitor-debug-multiple-7.png)
Sebuah eksekusi tugas untuk tugas Output dimulai dan menangkap file di lokasi pentahapan sebelum eksekusi tugas Input berikutnya mulai menempatkan lebih banyak data ke lokasi pentahapan. Selama hal tersebut berjalan seperti itu, ia hanya memproses file yang ditangkap dari eksekusi tugas Input sebelumnya, dan rasio tetap dekat dengan 1.
![\[Grafik yang menampilkan rasio pengaliran data: byte yang ditulis dan byte dibaca\]](http://docs.aws.amazon.com/id_id/glue/latest/dg/images/monitor-debug-multiple-7.png)
Misalkan tugas Input memakan waktu lebih lama dari yang diharapkan, maka sebagai akibatnya, tugas Output menangkap file di lokasi pentahapan dari dua eksekusi tugas Input. Rasio ini kemudian lebih tinggi dari 1 untuk eksekusi tugas output itu. Namun demikian, eksekusi tugas Output berikutnya tidak memproses file yang sudah diproses oleh eksekusi tugas dari tugas Output.
# Pemantauan perencanaan kapasitas DPU
Anda dapat menggunakan metrik pekerjaan AWS Glue untuk memperkirakan jumlah unit pemrosesan data (DPUs) yang dapat digunakan untuk skala AWS Glue pekerjaan.
**catatan**
Halaman ini hanya berlaku untuk AWS Glue versi 0.9 dan 1.0. Versi selanjutnya AWS Glue berisi fitur hemat biaya yang memperkenalkan pertimbangan tambahan saat perencanaan kapasitas.
**Topics**
+ [Kode diprofilkan](#monitor-debug-capacity-profile)
+ [Visualisasikan metrik yang diprofilkan di konsol AWS Glue](#monitor-debug-capacity-visualize)
+ [Tentukan kapasitas DPU yang optimal](#monitor-debug-capacity-fix)
## Kode diprofilkan
Skrip berikut membaca partisi Amazon Simple Storage Service (Amazon S3) yang berisi 428 file JSON gzip. Skrip tersebut menerapkan pemetaan untuk mengubah nama bidang, dan mengkonversi dan menuliskannya mereka ke Amazon S3 dalam format Apache Parquet. Anda menyediakan 10 DPUs sesuai default dan menjalankan pekerjaan ini.
```
datasource0 = glueContext.create_dynamic_frame.from_options(connection_type="s3", connection_options = {"paths": [input_path], "useS3ListImplementation":True,"recurse":True}, format="json")
applymapping1 = ApplyMapping.apply(frame = datasource0, mappings = [(map_spec])
datasink2 = glueContext.write_dynamic_frame.from_options(frame = applymapping1, connection_type = "s3", connection_options = {"path": output_path}, format = "parquet")
```
## Visualisasikan metrik yang diprofilkan di konsol AWS Glue
**Job run 1:** Dalam menjalankan pekerjaan ini kami menunjukkan cara mencari jika ada yang kurang disediakan DPUs di cluster. Fungsi eksekusi tugas di AWS Glue menampilkan total [jumlah pelaksana yang berjalan aktif](monitoring-awsglue-with-cloudwatch-metrics.md#glue.driver.ExecutorAllocationManager.executors.numberAllExecutors), [jumlah tahap yang telah selesai](monitoring-awsglue-with-cloudwatch-metrics.md#glue.driver.aggregate.numCompletedStages), dan [jumlah maksimal pelaksana yang dibutuhkan](monitoring-awsglue-with-cloudwatch-metrics.md#glue.driver.ExecutorAllocationManager.executors.numberMaxNeededExecutors).
Jumlah pelaksana maksimum yang dibutuhkan dihitung dengan menambahkan jumlah total tugas berjalan dan tugas yang tertunda, dan membaginya dengan tugas per pelaksana. Hasil ini adalah ukuran jumlah total pelaksana yang diperlukan untuk memenuhi beban saat ini.
Sebaliknya, jumlah pelaksana yang berjalan aktif mengukur berapa banyak pelaksana yang menjalankan tugas Apache Spark secara aktif. Saat tugas berlangsung, pelaksana maksimum yang diperlukan dapat mengubah dan biasanya turun menjelang akhir tugas saat antrean tugas tertunda berkurang.
Garis merah horizontal pada grafik berikut menunjukkan jumlah pelaksana maksimum yang dialokasikan, yang tergantung pada jumlah yang Anda alokasikan untuk pekerjaan DPUs itu. Dalam hal ini, Anda mengalokasikan 10 DPUs untuk menjalankan pekerjaan. Satu DPU dicadangkan untuk pengelolaan. Sembilan DPUs menjalankan dua pelaksana masing-masing dan satu eksekutor dicadangkan untuk driver Spark. Driver Spark berjalan dalam aplikasi utama. Jadi, jumlah maksimum pelaksana yang dialokasikan adalah 2\$19 - 1 = 17 pelaksana.
![\[Metrik tugas yang menunjukkan pelaksana aktif dan pelaksana maksimum yang dibutuhkan.\]](http://docs.aws.amazon.com/id_id/glue/latest/dg/images/monitor-debug-capacity-1.png)
Sebagaimana ditunjukkan dalam grafik, jumlah maksimum pelaksana yang diperlukan mulai pada 107 pada awal tugas, sedangkan jumlah pelaksana aktif tetap 17. Ini sama dengan jumlah pelaksana maksimum yang dialokasikan dengan 10. DPUs Rasio antara jumlah maksimum pelaksana yang dibutuhkan dan jumlah maksimum pelaksana yang dialokasikan (menambahkan 1 ke kedua driver Spark) memberi Anda faktor kurang-penyediaan: 108/18 = 6x. Anda dapat menyediakan 6 (di bawah rasio penyediaan) \$19 (kapasitas DPU saat ini - 1) \$1 1 DPUs = 55 DPUs untuk skala pekerjaan untuk menjalankannya dengan paralelisme maksimum dan menyelesaikan lebih cepat.
Konsol AWS Glue menampilkan metrik tugas detail sebagai garis statis yang mewakili jumlah asli dari jumlah maksimum pelaksana yang dialokasikan. Konsol menghitung pelaksana maksimum yang dialokasikan dari definisi tugas untuk metrik. Berdasarkan batasan, untuk metrik job run yang mendetail, konsol menghitung eksekutor maksimum yang dialokasikan dari konfigurasi job run, khususnya yang dialokasikan untuk menjalankan pekerjaan. DPUs Untuk melihat metrik masing-masing eksekusi tugas, pilih sebuah eksekusi tugas dan pilih **Lihat metrik eksekusi**.
![\[Metrik tugas yang menunjukkan pergerakan data ETL.\]](http://docs.aws.amazon.com/id_id/glue/latest/dg/images/monitor-debug-capacity-2.png)
Melihat byte Amazon S3 yang [di-baca](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.s3.filesystem.read_bytes) dan [di-tulis](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.s3.filesystem.write_bytes), perhatikan bahwa tugas menghabiskan waktu enam menit streaming data dari Amazon S3 dan menuliskannya secara paralel. Semua inti yang dialokasikan DPUs membaca dan menulis ke Amazon S3. Jumlah maksimum pelaksana yang dibutuhkan menjadi 107 juga cocok dengan jumlah file dalam input Amazon S3 path—yakni 428. Setiap pelaksana dapat meluncurkan empat tugas Spark untuk memproses empat file input (JSON gzip).
## Tentukan kapasitas DPU yang optimal
Berdasarkan hasil dari pekerjaan sebelumnya, Anda dapat meningkatkan jumlah total yang DPUs dialokasikan menjadi 55, dan melihat bagaimana kinerja pekerjaan. Tugas selesai dalam waktu kurang dari tiga menit—setengah dari waktu yang dibutuhkan sebelumnya. Penskalaan keluar tugas tidak linear dalam hal ini karena eksekusi tugas merupakan eksekusi tugas singkat. Pekerjaan dengan tugas yang berumur panjang atau sejumlah besar tugas (sejumlah besar pelaksana maksimum yang dibutuhkan) mendapat manfaat dari percepatan kinerja skala close-to-linear DPU.
![\[Grafik menunjukkan peningkatan jumlah total yang dialokasikan DPUs\]](http://docs.aws.amazon.com/id_id/glue/latest/dg/images/monitor-debug-capacity-3.png)
Sebagaimana yang ditunjukkan gambar di atas, jumlah pelaksana aktif mencapai jumlah pelaksana maksimum yang dialokasikan—yakni, 107 pelaksana. Demikian pula, jumlah pelaksana maksimum yang dibutuhkan tidak pernah berada di atas jumlah maksimum pelaksana yang dialokasikan. Jumlah maksimum pelaksana yang dibutuhkan dihitung dari jumlah tugas yang aktif berjalan dan tertunda, sehingga mungkin lebih kecil dari jumlah pelaksana aktif. Hal ini karena dapat ada pelaksana yang sebagian atau seluruhnya menganggur dalam waktu singkat dan belum dinonaktifkan.
![\[Grafik yang menunjukkan jumlah pelaksana aktif mencapai jumlah maksimum pelaksana yang dialokasikan.\]](http://docs.aws.amazon.com/id_id/glue/latest/dg/images/monitor-debug-capacity-4.png)
Eksekusi tugas ini menggunakan 6x pelaksana lebih untuk membaca dan menulis dari Amazon S3 secara paralel. Akibatnya, eksekusi tugas ini menggunakan lebih banyak bandwidth Amazon S3 untuk membaca dan menulis, dan selesai lebih cepat.
### Identifikasi kelebihan DPUs
Selanjutnya, Anda dapat menentukan apakah menskalakan pekerjaan dengan 100 DPUs (99 \$1 2 = 198 pelaksana) membantu untuk meningkatkan skala lebih jauh. Seperti yang ditunjukkan dalam grafik berikut, tugas masih membutuhkan waktu tiga menit untuk selesai. Demikian pula, pekerjaan tidak melampaui 107 eksekutor (55 DPUs konfigurasi), dan 91 eksekutor sisanya dilebih-lebihkan dan tidak digunakan sama sekali. Ini menunjukkan bahwa peningkatan jumlah DPUs mungkin tidak selalu meningkatkan kinerja, sebagaimana terbukti dari pelaksana maksimum yang dibutuhkan.
![\[Grafik yang menunjukkan bahwa kinerja pekerjaan tidak selalu meningkat dengan meningkatkan jumlah DPUs.\]](http://docs.aws.amazon.com/id_id/glue/latest/dg/images/monitor-debug-capacity-5.png)
### Bandingkan perbedaan waktu
Tiga pekerjaan berjalan yang ditunjukkan dalam tabel berikut merangkum waktu pelaksanaan pekerjaan untuk 10 DPUs, 55 DPUs, dan 100 DPUs. Anda dapat menemukan bahwa kapasitas DPU untuk meningkatkan waktu pelaksanaan tugas menggunakan perkiraan yang Anda buat dengan memantau tugas pertama.
| ID Tugas | Jumlah DPUs | Waktu eksekusi |
| --- | --- | --- |
| jr\$1c894524c8ef5048a4d9... | 10 | 6 menit. |
| jr\$11a466cf2575e7ffe6856... | 55 | 3 menit. |
| jr\$134fa1ed4c6aa9ff0a814... | 100 | 3 menit. |