Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Memecahkan masalah klaster EMR Amazon yang lambat
Bagian ini memandu Anda melalui proses pemecahan masalah klaster yang masih berjalan, tetapi membutuhkan waktu lama untuk mengembalikan hasil. Untuk informasi selengkapnya tentang apa yang harus dilakukan jika klaster diakhiri dengan kode kesalahan, lihat [Memecahkan masalah klaster EMR Amazon yang gagal dengan kode kesalahan](emr-troubleshoot-failed.md)
Amazon EMR mengizinkan Anda untuk menentukan jumlah dan jenis instans dalam klaster. Spesifikasi ini adalah sarana utama untuk memengaruhi kecepatan untuk menyelesaikan pemrosesan data Anda. Satu hal yang mungkin Anda pertimbangkan adalah menjalankan ulang klaster, kali ini menentukan instans EC2 dengan sumber daya yang lebih besar, atau menentukan jumlah instans yang lebih besar dalam klaster. Untuk informasi selengkapnya, lihat [Konfigurasikan perangkat keras dan jaringan cluster Amazon EMR](emr-plan-instances.md).
Topik berikut ini memandu Anda dalam proses mengidentifikasi penyebab alternatif klaster lambat.
**Topics**
+ [Langkah 1: Kumpulkan data tentang masalah dengan cluster EMR Amazon](emr-troubleshoot-slow-1.md)
+ [Langkah 2: Periksa lingkungan cluster EMR](emr-troubleshoot-slow-2.md)
+ [Langkah 3: Periksa file log untuk cluster Amazon EMR](emr-troubleshoot-slow-3.md)
+ [Langkah 4: Periksa klaster EMR Amazon dan kesehatan instans](emr-troubleshoot-slow-4.md)
+ [Langkah 5: Periksa grup yang ditangguhkan](emr-troubleshoot-slow-5.md)
+ [Langkah 6: Tinjau pengaturan konfigurasi untuk klaster EMR Amazon](emr-troubleshoot-slow-6.md)
+ [Langkah 7: Periksa data masukan untuk klaster EMR Amazon](emr-troubleshoot-slow-7.md)
# Langkah 1: Kumpulkan data tentang masalah dengan cluster EMR Amazon
Langkah pertama dalam pemecahan masalah klaster adalah mengumpulkan informasi tentang apa yang salah serta status dan konfigurasi klaster saat ini. Informasi ini akan digunakan dalam langkah-langkah berikut untuk mengkonfirmasi atau mengesampingkan kemungkinan penyebab masalah.
## Menentukan masalah
Definisi yang jelas tentang masalah yang terjadi adalah hal pertama yang dilakukan. Beberapa pertanyaan untuk Anda tanyakan pada diri sendiri:
+ Apa yang saya harapkan terjadi? Apa yang terjadi sebagai gantinya?
+ Kapan masalah ini pertama kali terjadi? Seberapa sering hal itu terjadi sejak pertama kali ditemukan?
+ Apakah ada yang berubah dalam cara saya mengonfigurasi atau menjalankan klaster saya?
## Detail klaster
Detail klaster berikut berguna dalam membantu melacak masalah. Untuk informasi selengkapnya tentang cara mengumpulkan informasi ini, lihat [Lihat status dan detail klaster EMR Amazon](emr-manage-view-clusters.md).
+ Pengidentifikasi klaster. (Juga disebut pengenal alur kerja.)
+ Wilayah AWS dan Availability Zone tempat cluster diluncurkan.
+ Status klaster, termasuk detail perubahan status terakhir.
+ Jenis dan jumlah instans EC2 yang ditentukan untuk simpul utama, inti, dan tugas.
# Langkah 2: Periksa lingkungan cluster EMR
Periksa lingkungan Anda untuk melihat apakah ada pemadaman layanan atau Anda telah melampaui batas AWS layanan.
**Topics**
+ [Periksa pemadaman layanan](#emr-troubleshoot-slow-2-outages)
+ [Periksa batas penggunaan](#emr-troubleshoot-slow-2-limits)
+ [Periksa konfigurasi subnet Amazon VPC](#emr-troubleshoot-slow-2-vpc)
+ [Memulai ulang klaster](#emr-troubleshoot-slow-2-restart)
## Periksa pemadaman layanan
Amazon EMR menggunakan beberapa Amazon Web Services secara internal. Ini menjalankan server virtual di Amazon EC2, menyimpan data dan skrip di Amazon S3, dan melaporkan metrik ke. CloudWatch Peristiwa yang mengganggu layanan ini jarang terjadi — tetapi ketika terjadi — dapat menyebabkan masalah di Amazon EMR.
Sebelum Anda melangkah lebih jauh, periksa [Service Health Dashboard](https://status.aws.amazon.com/). Periksa Wilayah tempat Anda meluncurkan klaster untuk melihat apakah ada peristiwa gangguan di salah satu layanan ini.
## Periksa batas penggunaan
Jika Anda meluncurkan cluster besar, telah meluncurkan banyak cluster secara bersamaan, atau Anda adalah pengguna yang berbagi Akun AWS dengan pengguna lain, cluster mungkin gagal karena Anda melebihi batas AWS layanan.
Amazon EC2 membatasi jumlah instans server virtual yang berjalan di satu AWS Wilayah hingga 20 instans sesuai permintaan atau cadangan. Jika Anda meluncurkan cluster dengan lebih dari 20 node, atau meluncurkan cluster yang menyebabkan jumlah total instans EC2 yang aktif pada Anda Akun AWS melebihi 20, cluster tidak akan dapat meluncurkan semua instans EC2 yang diperlukan dan mungkin gagal. Ketika ini terjadi, Amazon EMR mengembalikan kesalahan `EC2 QUOTA EXCEEDED`. Anda dapat meminta untuk AWS menambah jumlah instans EC2 yang dapat dijalankan di akun Anda dengan mengirimkan aplikasi [Permintaan untuk Meningkatkan Batas Instans Amazon EC2](https://aws.amazon.com/contact-us/ec2-request/).
Hal lain yang dapat menyebabkan Anda melebihi batas penggunaan Anda adalah penundaan antara ketika sebuah klaster diakhiri dan ketika klaster merilis seluruh sumber dayanya. Tergantung pada konfigurasinya, mungkin memakan waktu hingga 5-20 menit bagi klaster untuk sepenuhnya mengakhiri dan melepaskan sumber daya yang teralokasi. Jika Anda mendapatkan kesalahan `EC2 QUOTA EXCEEDED` ketika Anda mencoba untuk memulai sebuah klaster, ini mungkin karena sumber daya dari klaster yang baru diakhiri belum dirilis. Dalam kasus ini, Anda dapat [meminta kuota Amazon EC2 Anda ditingkatkan](https://aws.amazon.com/contact-us/ec2-request/), atau Anda dapat menunggu dua puluh menit dan meluncurkan ulang klaster tersebut.
Amazon S3 membatasi jumlah bucket yang dibuat pada sebuah akun hingga 100. Jika klaster Anda menciptakan bucket baru yang melebihi batas ini, pembuatan bucket akan gagal dan dapat menyebabkan klaster gagal.
## Periksa konfigurasi subnet Amazon VPC
Jika klaster Anda diluncurkan di subnet Amazon VPC, subnet harus dikonfigurasi seperti yang dijelaskan di [Konfigurasikan jaringan di VPC untuk Amazon EMR](emr-plan-vpc-subnet.md). Selain itu, periksa bahwa subnet tempat Anda meluncurkan klaster memiliki alamat IP elastis kosong yang cukup untuk menugaskan satu untuk setiap simpul dalam klaster.
## Memulai ulang klaster
Pelambatan dalam pemrosesan mungkin disebabkan oleh kondisi sementara. Pertimbangkan untuk mengakhiri dan memulai ulang klaster untuk melihat apakah performa meningkat.
# Langkah 3: Periksa file log untuk cluster Amazon EMR
Langkah berikutnya adalah memeriksa berkas log untuk menemukan kode kesalahan atau indikasi lain dari masalah yang dialami klaster Anda. Untuk informasi tentang berkas log yang tersedia, tempat menemukannya, dan bagaimana melihatnya, lihat [Lihat file log EMR Amazon](emr-manage-view-web-log-files.md).
Mungkin diperlukan beberapa pekerjaan investigasi untuk menentukan apa yang terjadi. Hadoop menjalankan pekerjaan dalam upaya tugas pada berbagai simpul dalam klaster. Amazon EMR dapat memulai upaya tugas spekulatif, mengakhiri upaya tugas lain yang tidak selesai terlebih dahulu. Hal ini menghasilkan aktivitas yang signifikan yang di-log ke berkas log pengendali, stderr dan syslog saat terjadi. Selain itu, beberapa upaya tugas berjalan secara bersamaan, tetapi berkas log hanya dapat menampilkan hasil secara linier.
Mulailah dengan memeriksa log tindakan bootstrap untuk mengetahui kesalahan atau perubahan konfigurasi yang tidak terduga selama peluncuran klaster. Dari sana, lihat di log langkah untuk mengidentifikasi pekerjaan Hadoop yang diluncurkan sebagai bagian dari langkah dengan kesalahan. Periksa log pekerjaan Hadoop untuk mengidentifikasi upaya tugas yang gagal. Log upaya tugas akan berisi detail tentang apa yang menyebabkan suatu upaya tugas gagal.
Bagian berikut ini menjelaskan cara menggunakan berbagai berkas log untuk mengidentifikasi kesalahan dalam klaster Anda.
## Periksa log tindakan bootstrap
Tindakan bootstrap menjalankan skrip pada klaster saat klaster diluncurkan. Mereka biasanya digunakan untuk menginstal perangkat lunak tambahan pada klaster atau untuk mengubah pengaturan konfigurasi dari nilai default. Memeriksa log ini dapat memberikan wawasan tentang kesalahan yang terjadi selama mengatur klaster serta perubahan pengaturan konfigurasi yang dapat mempengaruhi performa.
## Periksa log langkah
Ada empat jenis log langkah.
+ **pengendali -**Berisi file yang dihasilkan oleh Amazon EMR (Amazon EMR) yang muncul dari kesalahan yang dihadapi ketika mencoba untuk menjalankan langkah Anda. Jika langkah Anda gagal saat memuat, Anda dapat menemukan jejak tumpukan dalam log ini. Kesalahan memuat atau mengakses aplikasi Anda seringkali dijelaskan di sini, seperti kesalahan file pemeta hilang.
+ **stderr—**Berisi pesan kesalahan yang terjadi saat memproses langkah. Kesalahan memuat aplikasi sering kali dijelaskan di sini. Log ini kadang-kadang berisi jejak tumpukan.
+ **stdout -**Berisi status yang dihasilkan oleh pemeta dan peredam yang dapat dieksekusi. Kesalahan memuat aplikasi sering kali dijelaskan di sini. Log ini kadang-kadang berisi pesan kesalahan aplikasi.
+ **syslog—**Berisi log dari perangkat lunak non-Amazon, seperti Apache dan Hadoop. Kesalahan streaming seringkali dijelaskan di sini.
Periksa stderr untuk kesalahan yang jelas. Jika stderr menampilkan daftar singkat kesalahan, langkah akan segera berhenti dengan kesalahan yang terjadi. Hal ini paling sering disebabkan oleh kesalahan dalam aplikasi pemeta dan peredam yang dijalankan di klaster.
Periksa baris terakhir dari pengendali dan syslog untuk melihat pemberitahuan kesalahan atau kegagalan. Ikuti pemberitahuan tentang tugas yang gagal, terutama jika tertulis “Pekerjaan Gagal”.
## Periksa log upaya tugas
Jika analisis sebelumnya dari log langkah menimbulkan satu tugas yang gagal atau lebih, selidiki log dari upaya tugas yang sesuai untuk melihat informasi kesalahan yang lebih detail.
## Periksa log daemon Hadoop
Dalam kasus yang jarang terjadi, Hadoop sendiri mungkin gagal. Untuk melihat apakah itu yang terjadi, Anda harus melihat log Hadoop. Log ini ada di `/var/log/hadoop/` pada setiap simpul.
Anda dapat menggunakan JobTracker log untuk memetakan upaya tugas yang gagal ke simpul yang dijalankan. Setelah Anda mengetahui simpul yang terkait dengan upaya tugas tersebut, Anda dapat memeriksa kesehatan instans EC2 yang menjadi host simpul tersebut untuk melihat apakah ada masalah seperti kehabisan CPU atau memori.
# Langkah 4: Periksa klaster EMR Amazon dan kesehatan instans
Sebuah klaster Amazon EMR terdiri dari simpul yang berjalan di instans Amazon EC2. Jika instans tersebut terikat sumber daya (seperti kehabisan CPU atau memori), mengalami masalah konektivitas jaringan, atau diakhiri, kecepatan pemrosesan klaster akan terganggu.
Ada hingga tiga jenis simpul dalam sebuah klaster:
+ **Simpul Utama** — mengelola klaster. Jika mengalami masalah performa, seluruh klaster terpengaruh.
+ **Simpul Inti** — memproses tugas pemetaan-peredam dan memelihara Hadoop Distributed Filesystem (HDFS). Jika salah satu simpul ini mengalami masalah performa, hal itu dapat memperlambat operasi HDFS serta pemrosesan pemetaan-peredaman. Anda dapat menambahkan simpul inti tambahan ke suatu klaster untuk meningkatkan performa, tetapi tidak dapat menghapus simpul inti. Untuk informasi selengkapnya, lihat [Mengubah ukuran cluster EMR Amazon yang sedang berjalan secara manual](emr-manage-resize.md).
+ **simpul tugas** — memproses tugas pemetaan-peredaman. Simpul ini adalah sumber komputasi murni dan tidak menyimpan data. Anda dapat menambahkan simpul tugas ke sebuah klaster untuk mempercepat performa, atau menghapus simpul tugas yang tidak diperlukan. Untuk informasi selengkapnya, lihat [Mengubah ukuran cluster EMR Amazon yang sedang berjalan secara manual](emr-manage-resize.md).
Ketika Anda melihat kesehatan klaster, Anda harus melihat performa klaster secara keseluruhan, serta performa masing-masing instans. Ada beberapa alat yang dapat Anda gunakan:
## Periksa kesehatan cluster dengan CloudWatch
Setiap klaster EMR Amazon melaporkan metrik ke. CloudWatch Metrik ini memberikan ringkasan informasi performa tentang klaster, seperti total beban, pemanfaatan HDFS, tugas berjalan, tugas yang tersisa, blok yang rusak, dan banyak lagi. Melihat CloudWatch metrik memberi Anda gambaran besar tentang apa yang terjadi dengan cluster Anda dan dapat memberikan wawasan tentang apa yang menyebabkan perlambatan dalam pemrosesan. Selain menggunakan CloudWatch untuk menganalisis masalah kinerja yang ada, Anda dapat menyetel alarm yang CloudWatch menyebabkan peringatan jika terjadi masalah kinerja di masa mendatang. Untuk informasi selengkapnya, lihat [Memantau metrik Amazon EMR dengan CloudWatch](UsingEMR_ViewingMetrics.md).
## Periksa status pekerjaan dan kesehatan HDFS
Gunakan tab **Antarmuka pengguna aplikasi** pada halaman detail klaster untuk melihat detail aplikasi YARN. Untuk aplikasi tertentu, Anda dapat menelusuri detail lebih lanjut dan mengakses log secara langsung. Hal ini sangat berguna untuk aplikasi Spark. Untuk informasi selengkapnya, lihat [Lihat riwayat aplikasi Amazon EMR](emr-cluster-application-history.md).
Hadoop menyediakan serangkaian antarmuka web yang dapat Anda gunakan untuk melihat informasi. Untuk informasi selengkapnya tentang cara mengakses antarmuka web ini, lihat [Melihat antarmuka web yang di-host pada klaster Amazon EMR](emr-web-interfaces.md).
+ JobTracker — memberikan informasi tentang kemajuan pekerjaan yang sedang diproses oleh cluster. Anda dapat menggunakan antarmuka ini untuk mengidentifikasi kapan pekerjaan menjadi macet.
+ HDFS NameNode — memberikan informasi tentang persentase pemanfaatan HDFS dan ruang yang tersedia pada setiap node. Anda dapat menggunakan antarmuka ini untuk mengidentifikasi ketika HDFS menjadi terikat sumber daya dan membutuhkan kapasitas tambahan.
+ TaskTracker — memberikan informasi tentang tugas-tugas pekerjaan yang sedang diproses oleh cluster. Anda dapat menggunakan antarmuka ini untuk mengidentifikasi kapan tugas menjadi macet.
## Periksa kesehatan instans dengan Amazon EC2
Cara lain untuk mencari informasi tentang status instans di klaster Anda adalah dengan menggunakan konsol Amazon EC2. Karena setiap simpul dalam klaster berjalan pada instans EC2, Anda dapat menggunakan alat-alat yang disediakan oleh Amazon EC2 untuk memeriksa status mereka. Untuk informasi selengkapnya, lihat [Melihat instans klaster di Amazon EC2](UsingEMR_Tagging.md).
# Langkah 5: Periksa grup yang ditangguhkan
Grup instans menjadi ditangguhkan ketika ia menemui terlalu banyak kesalahan ketika mencoba untuk meluncurkan simpul. Sebagai contoh, jika simpul baru berulang kali gagal saat melakukan tindakan bootstrap, grup instans akan — setelah beberapa waktu — memasuki status `SUSPENDED` dan tidak terus mencoba untuk menyediakan simpul baru.
Suatu simpul dapat gagal muncul jika:
+ Hadoop atau klaster ternyata rusak dan tidak menerima simpul baru ke dalam klaster
+ Tindakan bootstrap gagal pada simpul baru
+ Simpul tidak berfungsi dengan benar dan gagal untuk check in dengan Hadoop
Jika grup instans berada pada status `SUSPENDED`, dan klaster berada dalam status `WAITING`, Anda dapat menambahkan langkah klaster untuk menyetel ulang jumlah simpul inti dan simpul tugas yang diinginkan. Menambahkan pemrosesan melanjutkan langkah klaster dan menempatkan grup instans kembali ke status `RUNNING`.
Untuk informasi selengkapnya tentang cara menyetel ulang klaster dalam keadaan ditangguhkan, lihat [Kondisi yang ditangguhkan](emr-manage-resize.md#emr-manage-resizeSuspended).
# Langkah 6: Tinjau pengaturan konfigurasi untuk klaster EMR Amazon
Pengaturan konfigurasi menentukan detail tentang bagaimana klaster berjalan, seperti berapa kali untuk mencoba kembali tugas dan berapa banyak memori tersedia untuk menyortir. Ketika Anda meluncurkan klaster menggunakan Amazon EMR, ada pengaturan khusus Amazon EMR selain pengaturan konfigurasi Hadoop standar. Pengaturan konfigurasi disimpan pada simpul utama klaster. Anda dapat memeriksa pengaturan konfigurasi untuk memastikan bahwa klaster Anda memiliki sumber daya yang diperlukan untuk berjalan secara efisien.
Amazon EMR mendefinisikan pengaturan konfigurasi default Hadoop yang digunakan untuk meluncurkan klaster. Nilai-nilainya didasarkan pada AMI dan tipe instans yang Anda tentukan untuk klaster. Anda dapat memodifikasi pengaturan konfigurasi ini dari nilai default menggunakan tindakan bootstrap atau dengan menentukan nilai-nilai baru dalam parameter eksekusi pekerjaan. Untuk informasi selengkapnya, lihat [Buat tindakan bootstrap untuk menginstal perangkat lunak tambahan dengan cluster EMR Amazon](emr-plan-bootstrap.md). Untuk menentukan apakah tindakan bootstrap mengubah pengaturan konfigurasi, periksa log tindakan bootstrap.
Amazon EMR mencatat pengaturan Hadoop yang digunakan untuk melaksanakan setiap pekerjaan. Data log disimpan dalam file bernama `job_job-id_conf.xml` di bawah `/mnt/var/log/hadoop/history/` direktori master node, di *job-id* mana digantikan oleh pengidentifikasi pekerjaan. Jika Anda telah mengaktifkan pengarsipan log, data ini disalin ke Amazon S3 di folder, `logs/date/jobflow-id/jobs` di *date* mana tanggal pekerjaan dijalankan, *jobflow-id* dan merupakan pengenal klaster.
Pengaturan konfigurasi pekerjaan Hadoop berikut ini sangat berguna untuk menyelidiki masalah performa. Untuk informasi selengkapnya tentang pengaturan konfigurasi Hadoop dan cara mereka mempengaruhi perilaku Hadoop, buka [http://hadoop.apache.org/docs/](http://hadoop.apache.org/docs/).
**Awas**
Pengaturan `dfs.replication` ke 1 pada cluster dengan kurang dari empat node dapat menyebabkan hilangnya data HDFS jika satu node turun. Kami menyarankan Anda menggunakan cluster dengan setidaknya empat node inti untuk beban kerja produksi.
Amazon EMR tidak akan mengizinkan cluster untuk menskalakan node inti di bawah ini. `dfs.replication` Misalnya, jika`dfs.replication = 2`, jumlah minimum node inti adalah 2.
Saat Anda menggunakan Penskalaan Terkelola, Penskalaan Otomatis, atau memilih untuk mengubah ukuran klaster secara manual, sebaiknya atur `dfs.replication` ke 2 atau lebih tinggi.
| Pengaturan konfigurasi | Deskripsi |
| --- | --- |
| dfs.replication | Jumlah simpul HDFS tempat menyalin blok tunggal (seperti blok hard drive) untuk menghasilkan lingkungan seperti RAID. Menentukan jumlah simpul HDFS yang berisi salinan blok. |
| io.sort.mb | Total memori yang tersedia untuk menyortir. Nilai ini harus 10x io.sort.factor. Pengaturan ini juga dapat digunakan untuk menghitung total memori yang digunakan oleh simpul tugas dengan mencari io.sort.mb dikalikan dengan mapred.tasktracker.ap.tasks.maximum. |
| io.sort.spill.percent | Digunakan selama penyortiran, ketika disk akan mulai digunakan karena memori penyortiran yang dialokasikan semakin penuh. |
| mapred.child.java.opts | Tidak lagi digunakan. Gunakan mapred.map.child.java.opts dan mapred.reduce.child.java.opts sebagai gantinya. Opsi Java TaskTracker digunakan saat meluncurkan JVM untuk tugas yang akan dijalankan di dalamnya. Parameter umum adalah “-Xmx” untuk pengaturan ukuran memori maks. |
| mapred.map.child.java.opts | Opsi Java TaskTracker digunakan saat meluncurkan JVM untuk tugas peta yang akan dijalankan di dalamnya. Parameter umum adalah “-Xmx” untuk pengaturan ukuran timbunan memori maks. |
| mapred.map.tasks.speculative.execution | Menentukan apakah upaya tugas pemetaan dari tugas yang sama dapat diluncurkan secara paralel. |
| mapred.reduce.tasks.speculative.execution | Menentukan apakah upaya tugas peredaman dari tugas yang sama dapat diluncurkan secara paralel. |
| mapred.map.max.attempts | Jumlah maksimum tugas pemetaan dapat dicoba. Jika semua gagal, maka tugas pemetaan ditandai sebagai gagal. |
| mapred.reduce.child.java.opts | Opsi Java TaskTracker digunakan saat meluncurkan JVM untuk tugas pengurangan yang akan dijalankan di dalamnya. Parameter umum adalah “-Xmx” untuk pengaturan ukuran timbunan memori maks. |
| mapred.reduce.max.attempts | Jumlah maksimum tugas peredaman dapat dicoba. Jika semua gagal, maka tugas pemetaan ditandai sebagai gagal. |
| mapred.reduce.slowstart.completed.maps | Jumlah tugas pemetaan yang harus diselesaikan sebelum tugas peredaman dicoba. Tidak menunggu cukup lama dapat menyebabkan kesalahan “Terlalu banyak kegagalan mengambil” dalam upaya. |
| mapred.reuse.jvm.num.tasks | Sebuah tugas berjalan dalam JVM tunggal. Menentukan berapa banyak tugas dapat menggunakan kembali JVM yang sama. |
| mapred.tasktracker.map.tasks.maximum | Jumlah maksimal tugas yang dapat dieksekusi secara paralel per simpul tugas selama pemetaan. |
| mapred.tasktracker.reduce.tasks.maximum | Jumlah maksimal tugas yang dapat dieksekusi secara paralel per simpul tugas selama peredaman. |
Jika tugas klaster Anda menggunakan banyak memori, Anda dapat meningkatkan performa dengan menggunakan lebih sedikit tugas per simpul inti dan mengurangi ukuran tumpukan pelacak pekerjaan Anda.
# Langkah 7: Periksa data masukan untuk klaster EMR Amazon
Lihatlah data input Anda. Apakah data terdistribusi secara merata di antara nilai-nilai kunci Anda? Jika data Anda sangat condong ke arah satu atau beberapa nilai kunci, beban pemrosesan dapat dipetakan ke sejumlah kecil simpul, sementara simpul lain menganggur. Distribusi pekerjaan yang tidak seimbang ini dapat mengakibatkan waktu pemrosesan yang lebih lambat.
Contoh himpunan data yang tidak seimbang adalah menjalankan klaster untuk mengurutkan kata-kata menurut abjad, tetapi memiliki himpunan data yang berisi kata-kata yang dimulai dengan huruf “a” saja. Ketika pekerjaan dipetakan, nilai pemrosesan simpul yang dimulai dengan “a” akan kewalahan, sementara simpul yang memproses kata-kata yang dimulai dengan huruf lain akan menganggur.