E-MapReduce：FAQ

Apa yang dimaksud dengan restart kluster stateful?

Restart kluster stateful mencakup restart ResourceManager dan restart NodeManager. ResourceManager mempertahankan informasi dasar serta status aplikasi, sedangkan NodeManager mempertahukan informasi dan status kontainer yang sedang berjalan. ResourceManager dan NodeManager secara terus-menerus menyinkronkan status mereka ke sistem penyimpanan eksternal seperti ZooKeeper, LevelDB, dan Hadoop Distributed File System (HDFS). Setelah di-restart, status ResourceManager dan NodeManager dapat dimuat ulang dan dipulihkan secara otomatis, sehingga memastikan bahwa status aplikasi dan kontainer juga pulih secara otomatis setelah peningkatan atau restart kluster. Dalam sebagian besar kasus, peningkatan atau restart kluster tidak terdeteksi oleh aplikasi dan kontainer.

Bagaimana cara mengaktifkan high availability (HA) ResourceManager?

Bagaimana cara mengonfigurasi pembaruan panas?

1. Konfigurasikan parameter utama.

   Anda dapat memeriksa atau mengonfigurasi parameter terkait pembaruan panas pada tab Configure di halaman layanan YARN kluster melalui konsol EMR. Tabel berikut menjelaskan parameter tersebut.

   Parameter	Deskripsi	Nilai yang direkomendasikan
   yarn.scheduler.configuration.store.class	Tipe penyimpanan cadangan. Jika Anda mengatur parameter ini ke fs, sistem file digunakan sebagai penyimpanan cadangan.	fs
   yarn.scheduler.configuration.max.version	Jumlah maksimum file konfigurasi yang dapat disimpan dalam sistem file. File konfigurasi yang berlebih akan dihapus secara otomatis jika jumlah file konfigurasi melebihi nilai parameter ini.	100
   yarn.scheduler.configuration.fs.path	Jalur tempat file capacity-scheduler.xml disimpan. Jika Anda tidak mengonfigurasi parameter ini, jalur penyimpanan akan dibuat secara otomatis. Jika tidak ada awalan yang ditentukan, jalur relatif dari sistem file default digunakan sebagai jalur penyimpanan.	/yarn/<Nama Kluster>/scheduler/conf Penting Ganti <Nama Kluster> dengan nama kluster spesifik. Beberapa kluster tempat layanan YARN diterapkan mungkin menggunakan penyimpanan terdistribusi yang sama.

2. Lihat konfigurasi file capacity-scheduler.xml.

   • Metode 1 (API RESTful): Akses URL dalam format berikut: http://<rm-address>/ws/v1/cluster/scheduler-conf.

   • Metode 2 (HDFS): Akses jalur konfigurasi ${yarn.scheduler.configuration.fs.path}/capacity-scheduler.xml.<timestamp> untuk melihat konfigurasi file capacity-scheduler.xml. <timestamp> menunjukkan waktu pembuatan file capacity-scheduler.xml. File capacity-scheduler.xml dengan nilai timestamp terbesar adalah file konfigurasi terbaru.

3. Perbarui konfigurasi.

   Sebagai contoh, Anda dapat memodifikasi parameter yarn.scheduler.capacity.maximum-am-resource-percent dan menghapus parameter yarn.scheduler.capacity.xxx. Untuk menghapus parameter, cukup hapus nilai bidang parameter tersebut.

   curl -X PUT -H "Content-type: application/json" 'http://<rm-address>/ws/v1/cluster/scheduler-conf' -d '
   {
     "global-updates": [
       {
         "entry": [{
           "key":"yarn.scheduler.capacity.maximum-am-resource-percent",
           "value":"0.2"
         },{
           "key":"yarn.scheduler.capacity.xxx"
         }]
       }
     ]
   }'

Bagaimana cara menangani distribusi sumber daya yang tidak merata di antara aplikasi dalam antrian?

Bagaimana cara melihat penggunaan sumber daya antrian?

Anda dapat melihat nilai parameter Used Capacity pada UI web YARN untuk memeriksa penggunaan sumber daya antrian. Parameter Used Capacity menunjukkan persentase sumber daya yang digunakan oleh antrian dibandingkan dengan total sumber daya yang dialokasikan ke antrian tersebut. Persentase penggunaan memori dan jumlah vCores dihitung secara terpisah, dengan nilai tertinggi di antara keduanya digunakan sebagai nilai parameter Used Capacity. Untuk melihat penggunaan sumber daya antrian, ikuti langkah-langkah berikut:

1. Akses UI web YARN. Untuk informasi lebih lanjut, lihat Akses UI web komponen open source.

2. Pada halaman All Applications, klik ID pekerjaan yang ingin diperiksa.

3. Klik antrian yang diinginkan pada baris Queue.

   Klik antrian yang diinginkan pada baris Queue. Di bagian Application Queues, tinjau penggunaan sumber daya antrian.

   

Sejumlah besar file log .out dihasilkan oleh komponen layanan YARN dan tidak dapat dibersihkan secara otomatis. Mengapa?

• Penyebab: Beberapa pustaka dependensi dari komponen Hadoop memanggil API logging Java untuk menghasilkan catatan log, namun tidak mendukung rotasi log berbasis Log4j. Output standar kesalahan (stderr) dari komponen daemon dialihkan ke file log .out. Karena mekanisme pembersihan otomatis tidak tersedia, akumulasi log yang berkepanjangan dapat menyebabkan penyimpanan disk terisi sepenuhnya.

• Solusi: Gunakan perintah head dan tail bersama dengan informasi timestamp dalam log untuk memeriksa apakah log yang dihasilkan oleh API logging Java memakan ruang penyimpanan yang signifikan. Umumnya, pustaka dependensi menghasilkan log tingkat INFO, yang tidak memengaruhi penggunaan komponen. Untuk mencegah penyimpanan disk terisi, Anda dapat memodifikasi konfigurasi untuk menonaktifkan pembuatan log tingkat INFO.

  Berikut adalah langkah-langkah untuk menonaktifkan pembuatan log pustaka dependensi Jersey Timeline Server:

  1. Jalankan perintah berikut untuk memantau file log .out yang relevan dengan timelineserver- di jalur penyimpanan log YARN. Di kluster DataLake, jalurnya adalah /var/log/emr/yarn/, sedangkan di kluster Hadoop, jalurnya adalah /mnt/disk1/log/hadoop-yarn.

     tail /var/log/emr/yarn/*-hadoop-timelineserver-*.out

     Output akan mencakup catatan yang dihasilkan oleh paket com.sun.jersey.

     

  2. Di node tempat Timeline Server dijalankan, jalankan perintah berikut sebagai root untuk membuat dan mengonfigurasi file guna menonaktifkan pembuatan log Timeline Server. Ini mencegah log tingkat INFO dari pustaka dependensi Jersey diekspor ke file log .out.

     sudo su root -c "echo 'com.sun.jersey.level = OFF' > $HADOOP_CONF_DIR/off-logging.properties"

  3. Di tab Configure halaman layanan YARN di konsol EMR, temukan parameter YARN_TIMELINESERVER_OPTS (setara dengan parameter yarn_timelineserver_opts di kluster Hadoop), dan tambahkan -Djava.util.logging.config.file=off-logging.properties ke nilai parameter untuk menentukan lokasi file konfigurasi yang telah dibuat.

     

  4. Simpan konfigurasi dan restart Timeline Server agar perubahan diterapkan. Jika Timeline Server dapat dimulai seperti yang diharapkan, dan file log .out tidak lagi berisi informasi log terkait com.sun.jersey, pembuatan log pustaka dependensi Jersey berhasil dinonaktifkan.

Bagaimana cara memeriksa apakah layanan ResourceManager normal?

Bagaimana cara mendapatkan status aplikasi?

Bagaimana cara menangani masalah untuk sebuah aplikasi?

1. Periksa status aplikasi. Anda dapat membuka halaman detail aplikasi atau memanggil API RESTful untuk melihat status aplikasi. Aplikasi mungkin berada dalam salah satu dari status berikut:

   • Status aplikasi tidak diketahui. Kemungkinan penyebab:

     • Aplikasi gagal dan keluar sebelum dikirimkan ke YARN. Dalam hal ini, periksa log pengiriman aplikasi untuk memastikan tidak ada masalah pada komponen klien seperti BRS dan FlowAgent.

     • Aplikasi tidak dapat terhubung ke ResourceManager. Pastikan titik akhir ResourceManager benar dan koneksi jaringan normal. Jika koneksi jaringan abnormal, kesalahan berikut mungkin muncul di klien: com.aliyun.emr.flow.agent.common.exceptions.EmrFlowException: ###[E40001,RESOURCE_MANAGER]: Gagal mengakses resource manager, cause: The stream is closed.

   • NEW_SAVING: Informasi aplikasi sedang ditulis ke penyimpanan status Zookeeper. Kemungkinan alasan aplikasi macet dalam status NEW_SAVING:

     • Kesalahan terjadi pada layanan ZooKeeper. Periksa apakah layanan ZooKeeper berfungsi dengan baik.

     • Kesalahan terjadi pada operasi baca atau tulis ZooKeeper. Untuk solusi lebih lanjut, lihat Apa yang harus dilakukan jika ResourceManager tidak dapat beralih secara otomatis dari keadaan Standby ke Active?.

   • SUBMITTED: Umumnya, aplikasi tidak berada dalam status ini. Namun, jika akuisisi kunci terjadi karena permintaan pembaruan node yang berlebihan di Capacity Scheduler dan menyebabkan pemblokiran, aplikasi mungkin berada dalam status SUBMITTED. Masalah ini sering terjadi di kluster berskala besar. Optimalkan prosedur pemrosesan permintaan untuk menyelesaikan masalah. Untuk informasi lebih lanjut, lihat YARN-9618.

   • ACCEPTED: Jika aplikasi berada dalam status ini, periksa informasi diagnostik dan pilih solusi berdasarkan pesan kesalahan:

     • Pesan kesalahan: Batas sumber daya AM antrian terlampaui.

       • Kemungkinan penyebab: Jumlah sumber daya ApplicationMaster (AM) yang digunakan dan diminta melebihi batas atas sumber daya AM dalam antrian. Penggunaan sumber daya AM harus mematuhi ketidaksamaan berikut: ${Used Application Master Resources} + ${AM Resource Request} < ${Max Application Master Resources}.

       • Solusi: Tingkatkan batas atas sumber daya AM dalam antrian. Contohnya, atur parameter yarn.scheduler.capacity.<queue-path>.maximum-am-resource-percent menjadi 0.5.

     • Pesan kesalahan: Batas sumber daya AM pengguna terlampaui.

       • Kemungkinan penyebab: Jumlah sumber daya AM yang digunakan dan diminta melebihi batas atas sumber daya AM dalam antrian untuk pengguna tertentu.

       • Solusi: Tingkatkan batas atas sumber daya AM dalam antrian untuk pengguna tersebut. Contohnya, modifikasi parameter yarn.scheduler.capacity.<queue-path>.user-limit-factor dan yarn.scheduler.capacity.<queue-path>.minimum-user-limit-percent.

     • Pesan kesalahan: Kontainer AM diluncurkan, menunggu kontainer AM untuk mendaftar dengan RM.

       • Kemungkinan penyebab: AM dimulai tetapi inisialisasi belum selesai, misalnya karena koneksi ZooKeeper habis waktu.

       • Solusi: Lakukan pemecahan masalah lebih lanjut berdasarkan log AM.

     • Pesan kesalahan: Aplikasi diaktifkan, menunggu sumber daya dialokasikan untuk AM.

       Lakukan Langkah 3 untuk menganalisis penyebab sumber daya AM yang tidak memadai.

   • RUNNING: Jika aplikasi berada dalam status ini, lakukan Langkah 2 untuk memeriksa apakah permintaan sumber daya kontainer lengkap.

   • FAILED: Jika aplikasi berada dalam status ini, periksa informasi diagnostik dan pilih solusi berdasarkan pesan kesalahan:

     • Pesan kesalahan: Batas aplikasi sistem maksimum tercapai, tidak dapat menerima pengiriman aplikasi.

       • Kemungkinan penyebab: Jumlah aplikasi yang berjalan di kluster melebihi batas atas yang ditentukan oleh parameter yarn.scheduler.capacity.maximum-applications. Nilai default parameter ini adalah 10.000.

       • Solusi: Periksa metrik Java Management Extensions (JMX) untuk memastikan jumlah aplikasi yang berjalan di setiap antrian sesuai dengan harapan. Lakukan pemecahan masalah pada aplikasi yang dikirimkan secara berulang. Jika semua aplikasi berfungsi dengan baik, Anda dapat menetapkan parameter ke nilai yang lebih besar berdasarkan Penggunaan kluster.

     • Pesan kesalahan: Aplikasi XXX yang dikirimkan oleh pengguna YYY ke antrian tidak dikenal: ZZZ.

       • Penyebab potensial: Aplikasi dikirimkan ke antrian yang tidak tersedia.

       • Solusi: Kirim aplikasi ke antrian daun yang valid.

     • Pesan kesalahan: Aplikasi XXX yang dikirimkan oleh pengguna YYY ke antrian tidak dikenal: ZZZ.

       • Kemungkinan penyebab: Aplikasi telah dikirim ke antrian induk.

       • Solusi: Kirim aplikasi ke antrian daun yang ada.

     • Pesan kesalahan: Antrian XXX telah BERHENTI. Tidak dapat menerima pengiriman aplikasi: YYY.

       • Kemungkinan penyebab: Aplikasi dikirimkan ke antrian induk.

       • Solusi: Kirim aplikasi ke antrian daun yang ada.

     • Pesan kesalahan: Antrian XXX sudah memiliki YYY aplikasi dan tidak dapat menerima pengajuan aplikasi: ZZZ.

       • Kemungkinan penyebab: Jumlah aplikasi dalam antrian mencapai batas maksimum.

       • Solusi:

         1. Periksa apakah sejumlah besar aplikasi diajukan berulang kali ke antrian.

         2. Ubah parameter yarn.scheduler.capacity.<queue-path>.maximum-applications.

     • Pesan kesalahan: Antrian XXX sudah memiliki YYY aplikasi, tidak dapat menerima pengiriman aplikasi: ZZZ.

       • Kemungkinan penyebab: Jumlah aplikasi dalam antrian untuk seorang pengguna mencapai batas maksimum.

       • Solusi:

         1. Periksa apakah sejumlah besar aplikasi secara berulang dikirimkan ke antrian untuk pengguna tersebut.

         2. Ubah parameter yarn.scheduler.capacity.<queue-path>.maximum-applications, yarn.scheduler.capacity.<queue-path>.minimum-user-limit-percent, dan yarn.scheduler.capacity.<queue-path>.user-limit-factor.

2. Verifikasi bahwa alokasi sumber daya YARN belum selesai.

   1. Pada halaman daftar aplikasi, klik ID aplikasi untuk membuka halaman detail aplikasi.

   2. Klik ID percobaan aplikasi pada halaman detail aplikasi untuk membuka halaman detail percobaan aplikasi.

   3. Periksa apakah ada sumber daya dalam keadaan Pending di daftar Total Outstanding Resource Requests. Anda juga dapat memeriksa sumber daya dalam keadaan Pending dengan memanggil RESTful API untuk permintaan tertunda.

      • Jika tidak ada sumber daya dalam keadaan Pending, maka alokasi sumber daya YARN telah selesai. Keluar dari prosedur pemecahan masalah dan periksa alokasi sumber daya AM.

      • Jika ada sumber daya dalam keadaan Pending, maka alokasi sumber daya YARN belum selesai. Lanjutkan ke langkah berikutnya.

3. Periksa batas pada sumber daya.

   Periksa sumber daya dalam kluster atau dalam antrian. Contohnya, periksa nilai parameter Effective Max Resource dan Used Resources.

   1. Periksa apakah sumber daya berikut telah sepenuhnya digunakan: sumber daya dalam kluster, sumber daya dalam antrian, atau sumber daya dalam antrian induk.

   2. Periksa apakah sumber daya dari dimensi dalam antrian daun mendekati atau mencapai batas atas.

   3. Jika penggunaan sumber daya dalam kluster mendekati 100%, seperti lebih dari 85%, kecepatan alokasi sumber daya ke aplikasi mungkin menurun. Salah satu alasannya adalah bahwa sebagian besar mesin tidak memiliki sumber daya. Jika sebuah mesin tidak memiliki sumber daya untuk dialokasikan, mesin tersebut akan dicadangkan. Jika jumlah mesin yang dicadangkan mencapai angka tertentu, kecepatan alokasi sumber daya mungkin menurun. Alasan lain yang mungkin adalah ketidakseimbangan antara sumber daya memori dan CPU. Contohnya, beberapa mesin memiliki sumber daya memori yang menganggur tetapi tidak memiliki sumber daya CPU yang menganggur, dan sebaliknya.

4. Periksa apakah sumber daya berhasil dialokasikan ke sebuah container tetapi container gagal memulai. Di halaman App Attempt pada antarmuka web YARN, Anda dapat melihat jumlah container yang dialokasikan sumber dayanya dan perubahan jumlah container dalam periode waktu singkat. Jika sebuah container gagal memulai, lakukan pemecahan masalah berdasarkan log NodeManager atau log dari container tersebut.

5. Secara dinamis menyesuaikan tingkat log. Di halaman Tingkat Log dari antarmuka web YARN di http://RM_IP:8088/logLevel, ubah tingkat log untuk parameter org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity menjadi DEBUG. Parameter ini menunjukkan paket dari Capacity Scheduler. Gambar berikut memberikan contohnya.

   Penting

   Anda dapat menyesuaikan tingkat log saat mereproduksi masalah dan mengubah kembali tingkat log ke INFO setelah puluhan detik. Hal ini karena banyak log dapat dihasilkan dalam waktu singkat.

Parameter apa yang menentukan jumlah maksimum sumber daya yang tersedia untuk satu tugas atau kontainer?

Apa yang harus dilakukan jika modifikasi konfigurasi YARN tidak berlaku?

• Kemungkinan Penyebab:

  • Untuk konfigurasi lainnya, komponen terkait belum di-restart.

  • Untuk konfigurasi pembaruan panas, operasi tertentu yang diperlukan agar konfigurasi berlaku belum dilakukan.

• Solusi: Pastikan semua operasi yang diperlukan untuk penerapan konfigurasi telah dilakukan dengan benar.

  File konfigurasi	Kategori	Operasi selanjutnya
  capacity-scheduler.xml fair-scheduler.xml	Konfigurasi penjadwal	Lakukan operasi refresh_queues pada ResourceManager. Konfigurasi ini adalah konfigurasi pembaruan panas.
  yarn-env.sh yarn-site.xml mapred-env.sh mapred-site.xml	Konfigurasi komponen YARN	Mulai ulang komponen yang terkait dengan konfigurasi. Contohnya: Mulai ulang ResourceManager setelah Anda memodifikasi parameter YARN_RESOURCEMANAGER_HEAPSIZE di file yarn-env.sh atau parameter yarn.resourcemanager.nodes.exclude-path di file yarn-site.xml. Mulai ulang NodeManager setelah Anda memodifikasi parameter YARN_NODEMANAGER_HEAPSIZE di file yarn-env.sh atau parameter yarn.nodemanager.log-dirs di file yarn-site.xml. Mulai ulang MRHistoryServer setelah Anda memodifikasi parameter MAPRED_HISTORYSERVER_OPTS di file mapred-env.sh atau parameter mapreduce.jobhistory.http.policys di file mapred-site.xml.

Apa yang harus dilakukan jika pesan kesalahan berikut dilaporkan untuk pengecualian yang terjadi pada klien aplikasi: Exception while invoking getClusterNodes of class ApplicationClientProtocolPBClientImpl over rm2 after 1 fail over attempts. Trying to fail over immediately?

• Deskripsi Masalah: ResourceManager aktif tidak dapat diakses. Log ResourceManager mencatat informasi pengecualian berikut: WARN org.apache.hadoop.ipc.Server: Header atau versi salah dari 10.33.**.**:53144 got version 6 expected version 9.

• Penyebab: Versi Hadoop yang lebih lama digunakan. Versi remote procedure call (RPC) pada klien aplikasi tidak kompatibel dengan versi Hadoop.

• Solusi: Gunakan versi Hadoop yang kompatibel dengan versi RPC klien aplikasi.

Apa yang harus dilakukan jika ResourceManager tidak dapat beralih secara otomatis dari keadaan Standby ke keadaan Aktif?

Apa yang harus dilakukan jika terjadi masalah OOM di ResourceManager?

Mengapa lokalisasi gagal ketika sebuah node mulai menjalankan pekerjaan, dan mengapa log pekerjaan tidak dapat dikumpulkan atau dihapus?

• Deskripsi masalah: Log NodeManager mencatat informasi pengecualian berikut: java.io.IOException: Couldn't create proxy provider class org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider.

• Penyebab: Konfigurasi HDFS salah.

• Solusi:

  1. Pesan pengecualian tersebut dienkapsulasi dan bukan penyebab utama masalah. Untuk menemukan penyebab utama, periksa log tingkat debug.

     • Di antarmuka baris perintah (CLI) untuk klien Hadoop, jalankan perintah seperti hadoop fs -ls / untuk mengakses Hadoop. Kemudian, aktifkan debugging dengan menjalankan perintah berikut:

       export HADOOP_LOGLEVEL=DEBUG

     • Dalam lingkungan runtime dengan konfigurasi Log4j, tambahkan log4j.logger.org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider=DEBUG ke akhir file konfigurasi Log4j.

  2. Gambar berikut menunjukkan bahwa penyebab utama masalah adalah pengguna memodifikasi konfigurasi NameServices. Pengguna mengubah emr-cluster menjadi hadoop-emr-cluster. Namun, node baru menggunakan konfigurasi NameServices asli setelah penskalaan keluar.

  3. Di tab Configure halaman layanan HDFS kluster pada konsol EMR, pastikan parameter telah dikonfigurasi dengan benar.

Bagaimana cara menangani pengecualian lokalisasi sumber daya?

• Deskripsi Masalah:

  • Kontainer AM yang digunakan untuk memproses pekerjaan gagal memulai, dengan pesan kesalahan berikut dilaporkan:

    Aplikasi application_1412960082388_788293 gagal 2 kali karena Kontainer AM untuk appattempt_1412960082388_788293_000002 keluar dengan exitCode: -1000 karena EPERM: Operasi tidak diizinkan. Informasi pengecualian tersebut adalah informasi diagnostik tentang pekerjaan yang gagal.

  • Kesalahan terjadi saat paket sumber daya aplikasi diekstraksi setelah diunduh untuk lokalisasi sumber daya. Periksa log NodeManager berikut untuk informasi lebih lanjut:

    INFO org.apache.hadoop.yarn.server.nodemanager.containermanager.localizer.ResourceLocalizationService: Gagal mengunduh rsrc { { hdfs://hadoopnnvip.cm6:9000/user/heyuan.lhy/apv/small_apv_20141128.tar.gz, 1417144849604, ARCHIVE, null },pending,[(container_1412960082388_788293_01_000001)],14170282104675332,DOWNLOADING}
    EPERM: Operasi tidak diizinkan
            at org.apache.hadoop.io.nativeio.NativeIO$POSIX.chmodImpl(Native Method)
            at org.apache.hadoop.io.nativeio.NativeIO$POSIX.chmod(NativeIO.java:226)
            at org.apache.hadoop.fs.RawLocalFileSystem.setPermission(RawLocalFileSystem.java:629)
            at org.apache.hadoop.fs.DelegateToFileSystem.setPermission(DelegateToFileSystem.java:186)
            at org.apache.hadoop.fs.FilterFs.setPermission(FilterFs.java:235)
            at org.apache.hadoop.fs.FileContext$10.next(FileContext.java:949)
            at org.apache.hadoop.fs.FileContext$10.next(FileContext.java:945)
            at org.apache.hadoop.fs.FSLinkResolver.resolve(FSLinkResolver.java:90)
            at org.apache.hadoop.fs.FileContext.setPermission(FileContext.java:945)
            at org.apache.hadoop.yarn.util.FSDownload.changePermissions(FSDownload.java:398)
            at org.apache.hadoop.yarn.util.FSDownload.changePermissions(FSDownload.java:412)
            at org.apache.hadoop.yarn.util.FSDownload.changePermissions(FSDownload.java:412)
            at org.apache.hadoop.yarn.util.FSDownload.call(FSDownload.java:352)
            at org.apache.hadoop.yarn.util.FSDownload.call(FSDownload.java:57)
            at java.util.concurrent.FutureTask.run(FutureTask.java:262)
            at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
            at java.util.concurrent.FutureTask.run(FutureTask.java:262)
            at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
            at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
            at java.lang.Thread.run(Thread.java:744)

• Penyebab: Paket sumber daya aplikasi mengandung tautan simbolik, yang menyebabkan pengecualian lokalisasi sumber daya.

• Solusi: Hapus tautan simbolik dari paket sumber daya aplikasi.

Apa yang harus dilakukan jika pesan kesalahan "No space left on device" ditampilkan dan kontainer gagal memulai atau berjalan?

Nama domain gagal diselesaikan di NodeManager atau selama pekerjaan berjalan. Apa yang harus dilakukan?

• Deskripsi masalah: Pesan kesalahan berikut muncul: java.net.UnknownHostException: Nama host tidak valid: local host is: (unknown).

• Penyebab potensial dan solusi:

  • Periksa apakah server Domain Name System (DNS) dikonfigurasi dengan benar.

    Jalankan perintah berikut untuk memeriksa konfigurasi server DNS:

    cat /etc/resolv.conf

  • Periksa apakah aturan yang diperlukan telah dikonfigurasikan untuk Port 53 firewall.

    Jika aturan yang diperlukan telah dikonfigurasikan, nonaktifkan firewall.

  • Periksa apakah layanan Name Service Cache Daemon (NSCD) diaktifkan untuk server DNS.

    Jalankan perintah berikut untuk memeriksa status layanan NSCD:

    systemctl status nscd

    Jika layanan NSCD diaktifkan untuk server DNS, jalankan perintah berikut untuk menonaktifkan layanan NSCD:

    systemctl stop nscd

Apa yang harus dilakukan jika terjadi masalah OOM di NodeManager?

Setelah instance ECS di-restart, NodeManager gagal dimulai karena direktori cgroups hilang. Apa yang harus dilakukan?

• Pesan kesalahan: ResourceHandlerException: Unexpected: Cannot create yarn cgroup Subsystem:cpu Mount point:/proc/mounts User:hadoop Path:/sys/fs/cgroup/cpu/hadoop-yarn

• Penyebab: Restart abnormal instance ECS kemungkinan disebabkan oleh cacat kernel pada instance tersebut. Ini merupakan masalah yang diketahui di versi 4.19.91-21.2.al7.x86_64. Setelah instance ECS di-restart, cgroups menjadi tidak valid karena data cgroups di memori dihapus setelah restart.

• Solusi: Modifikasi skrip bootstrap grup node untuk membuat direktori cgroups di kluster. Jalankan skrip rc.local untuk membuat direktori jika instance ECS dimulai. Contoh kode berikut mengilustrasikan langkah-langkahnya:

  # aktifkan cgroups
  mkdir -p /sys/fs/cgroup/cpu/hadoop-yarn
  chown -R hadoop:hadoop /sys/fs/cgroup/cpu/hadoop-yarn
  # aktifkan cgroups setelah reboot
  echo "mkdir -p /sys/fs/cgroup/cpu/hadoop-yarn" >> /etc/rc.d/rc.local
  echo "chown -R hadoop:hadoop /sys/fs/cgroup/cpu/hadoop-yarn" >> /etc/rc.d/rc.local
  chmod +x /etc/rc.d/rc.local

Apa yang harus dilakukan jika konfigurasi sumber daya NodeManager tidak berlaku setelah saya menyimpan konfigurasi dan me-restart NodeManager?

• Deskripsi: Parameter yarn.nodemanager.resource.cpu-vcores dan yarn.nodemanager.resource.memory-mb telah dimodifikasi dan disimpan, namun konfigurasi tidak diterapkan setelah NodeManager di-restart.

• Penyebab: Jumlah core CPU dan ukuran memori instance dalam grup node mungkin berbeda-beda. Modifikasi parameter yarn.nodemanager.resource.cpu-vcores dan yarn.nodemanager.resource.memory-mb untuk grup node diperlukan agar pengaturan dapat diterapkan.

• Solusi: Masuk ke konsol E-MapReduce (EMR). Pada tab Configure halaman layanan YARN, pilih Konfigurasi Grup Node dari daftar drop-down di sebelah kanan kotak pencarian, lalu pilih grup node tempat NodeManager berada. Selanjutnya, modifikasi parameter yarn.nodemanager.resource.cpu-vcores dan yarn.nodemanager.resource.memory-mb. Untuk informasi lebih lanjut, lihat Kelola item konfigurasi.

Apa yang harus dilakukan jika sebuah node ditandai sebagai tidak sehat?

• Penyebab:

  • Pengecualian terdeteksi selama pemeriksaan kesehatan disk: Jika rasio jumlah direktori normal terhadap jumlah total direktori di node lebih rendah dari nilai yang ditentukan, node akan ditandai sebagai tidak sehat. Rasio ini dikontrol oleh parameter yarn.nodemanager.disk-health-checker.min-healthy-disks dalam file yarn-site.xml. Nilai default untuk parameter ini adalah 0,25. Misalnya, jika empat disk digunakan pada node tempat NodeManager berada, node hanya akan ditandai sebagai tidak sehat jika semua empat disk mengalami masalah. Jika tidak, pesan "local-dirs are bad" atau "log-dirs are bad" akan dicatat dalam laporan status NodeManager. Untuk informasi lebih lanjut, lihat Apa yang Harus Dilakukan Jika Pesan "local-dirs are bad" atau "log-dirs are bad" Dilaporkan?.

  • Pengecualian terdeteksi oleh skrip pemeriksaan kesehatan NodeManager: Secara default, skrip ini dinonaktifkan. Anda perlu mengonfigurasi parameter yarn.nodemanager.health-checker.script.path dalam file yarn-site.xml untuk mengaktifkan skrip pemeriksaan kesehatan.

• Solusi:

  • Jika masalah disebabkan oleh pengecualian disk, lihat solusi di bagian Apa yang Harus Dilakukan Jika Pesan "local-dirs are bad" atau "log-dirs are bad" Dilaporkan?.

  • Jika masalah terdeteksi oleh skrip pemeriksaan kesehatan, selesaikan masalah sesuai dengan logika skrip kustom yang digunakan.

Apa yang harus dilakukan jika pesan "local-dirs are bad" atau "log-dirs are bad" muncul?

• Penyebab: Pengecualian terdeteksi selama pemeriksaan kesehatan disk. Secara default, fitur pemeriksaan kesehatan disk diaktifkan dan secara berkala memeriksa apakah local-dirs dan log-dirs memenuhi kondisi tertentu. Local-dirs adalah direktori cache tugas yang menyimpan file dan data perantara untuk menjalankan tugas, sedangkan log-dirs adalah direktori log tugas yang menyimpan semua log tugas. Jika salah satu dari kondisi berikut tidak terpenuhi, local-dirs atau log-dirs ditandai sebagai buruk:

  • Dapat dibaca.

  • Dapat ditulis.

  • Dapat dieksekusi.

  • Penggunaan disk lebih rendah dari ambang batas yang ditentukan oleh parameter yarn.nodemanager.disk-health-checker.max-disk-utilization-per-disk-percentage di file yarn-site.xml. Nilai default parameter ini adalah 90%.

    Ruang disk tersisa lebih besar dari ruang minimum yang tersedia yang ditentukan oleh parameter yarn.nodemanager.disk-health-checker.min-free-space-per-disk-mb di file yarn-site.xml. Nilai default parameter ini adalah 0 MB.

• Solusi:

  • Dalam kebanyakan kasus, masalah disebabkan oleh ruang disk yang tidak mencukupi. Jika salah satu dari kondisi berikut terpenuhi, kami sarankan Anda menambah kapasitas disk:

    • Spesifikasi node tempat NodeManager berada tinggi, dan sejumlah besar tugas berjalan di node tersebut.

    • Ruang disk kecil.

    • Ukuran data atau file yang diperlukan untuk menjalankan tugas besar.

    • Sejumlah besar data perantara dihasilkan saat tugas berjalan.

    • Ukuran log tugas besar, dan log tugas menempati proporsi tinggi dari ruang disk.

  • Periksa parameter yarn.nodemanager.localizer.cache.target-size-mb di file yarn-site.xml. Jika rasio ukuran cache terhadap ukuran disk terlalu besar, sebagian besar ruang disk akan ditempati oleh data cache tugas karena cache hanya dapat dibersihkan secara otomatis jika ambang batas tertentu terlampaui.

  • Perbaiki disk yang rusak. Untuk informasi lebih lanjut tentang cara memperbaiki disk yang rusak, lihat Ganti disk lokal yang rusak untuk kluster EMR.

Apa yang harus dilakukan jika pesan kesalahan "User [dr.who] is not authorized to view the logs for application ***" ditampilkan?

• Deskripsi masalah: Informasi berikut muncul saat halaman log dibuka.

• Penyebab: Aturan Daftar Kontrol Akses (ACL) diperiksa saat mengakses halaman Log NodeManager. Jika aturan ACL diaktifkan, pengguna jarak jauh yang ingin melihat log aplikasi harus memenuhi salah satu kondisi berikut:

  • Pengguna remote adalah admin.

  • Pengguna remote adalah pemilik aplikasi.

  • Pengguna remote memenuhi aturan ACL yang disesuaikan untuk aplikasi.

• Solusi: Pastikan pengguna remote memenuhi salah satu kondisi yang telah disebutkan.

Apa yang harus saya lakukan jika pesan kesalahan "HTTP ERROR 401 Authentication required" atau "HTTP ERROR 403 Unauthenticated users are not authorized to access this page" ditampilkan?

• Deskripsi masalah: Kesalahan HTTP ERROR 401 atau HTTP ERROR 403 terjadi saat mengakses antarmuka web atau memanggil API RESTful. Detail dari HTTP ERROR 401 ditampilkan pada gambar berikut.

  

• Penyebab: YARN menggunakan metode autentikasi sederhana dan tidak mengizinkan akses anonim. Untuk informasi lebih lanjut, lihat Autentikasi untuk Hadoop HTTP web-consoles di dokumentasi resmi Apache Hadoop.

• Solusi:

  • Metode 1: Konfigurasikan parameter URL untuk menentukan pengguna jarak jauh, seperti user.name=***.

  • Metode 2: Di bagian Configuration Filter pada tab Configure halaman layanan HDFS kluster di konsol EMR, cari parameter hadoop.http.authentication.simple.anonymous.allowed dan ubah nilai parameternya menjadi true untuk mengizinkan akses anonim. Untuk informasi lebih lanjut tentang parameter ini, lihat Autentikasi untuk Hadoop HTTP web-consoles di dokumentasi resmi Apache Hadoop. Kemudian, mulai ulang layanan HDFS. Untuk informasi lebih lanjut, lihat Mulai ulang layanan.

Mengapa nilai tampilan TotalVcore salah?

Di bagian cluster atau metrics RESTful API di pojok kanan atas antarmuka web YARN, nilai tampilan TotalVcore salah. Masalah ini disebabkan oleh logika perhitungan untuk TotalVcore pada versi Apache Hadoop sebelum 2.9.2. Untuk informasi lebih lanjut, lihat Total #VCores dalam cluster metrics salah ketika CapacityScheduler memesan beberapa kontainer di dokumentasi resmi Apache Hadoop.

Masalah ini telah diperbaiki di EMR V3.37.x, EMR V5.3.x, dan versi minor berikutnya.

Apa yang harus saya lakukan jika informasi tentang aplikasi yang ditampilkan di antarmuka web TEZ tidak lengkap?

Mengapa tugas Spark Thrift JDBC/ODBC Server berjalan di web UI YARN?

Jika Anda memilih Spark saat membuat kluster, layanan Spark Thrift Server akan otomatis dimulai secara default. Layanan ini menggunakan sumber daya dari satu driver YARN. Secara default, tugas yang dijalankan di Spark Thrift Server meminta sumber daya yang diperlukan dari YARN melalui driver ini.

Apakah parameter yarn.timeline-service.leveldb-timeline-store.path dapat diatur ke URL Bucket OSS?

Tidak, parameter yarn.timeline-service.leveldb-timeline-store.path tidak dapat diatur ke URL Bucket OSS.

Jika kluster yang Anda buat adalah kluster Hadoop, nilai default dari parameter yarn.timeline-service.leveldb-timeline-store.path sama dengan nilai parameter hadoop.tmp.dir. Jangan ubah parameter hadoop.tmp.dir, karena hal ini akan memengaruhi pengaturan parameter yarn.timeline-service.leveldb-timeline-store.path.

Apa yang harus saya lakukan jika koneksi ke Timeline Server mengalami timeout atau beban CPU atau penggunaan memori sangat tinggi?

Jika terdapat sejumlah besar pekerjaan Tez, koneksi ke Timeline Server dari YARN dapat mengalami timeout saat data ditulis ke Timeline Server. Hal ini disebabkan oleh penggunaan sumber daya CPU yang tinggi oleh proses Timeline Server, sehingga beban CPU pada node tempat server berjalan mencapai batas maksimum. Akibatnya, layanan non-inti seperti pembuatan laporan dan pengembangan pekerjaan lainnya terpengaruh. Untuk mengurangi beban CPU pada node, Anda dapat sementara menghentikan proses Timeline Server. Selain itu, Anda dapat menambahkan atau memodifikasi item konfigurasi berikut untuk menyelesaikan masalah ini.

Tambahkan atau modifikasi konfigurasi layanan Tez dan YARN melalui konsol EMR. Untuk informasi lebih lanjut, lihat Kelola Item Konfigurasi.

1. Buka tab tez-site.xml di tab Configure halaman layanan Tez di konsol EMR. Tambahkan item konfigurasi dengan nama tez.yarn.ats.event.flush.timeout.millis dan nilai 60000. Item konfigurasi ini menentukan periode timeout yang diizinkan saat pekerjaan Tez menulis peristiwa ke Timeline Server YARN.

2. Buka tab yarn-site.xml di tab Configure halaman layanan YARN di konsol EMR, lalu tambahkan atau modifikasi item konfigurasi sesuai tabel berikut. Setelah penambahan atau modifikasi selesai, mulai ulang Timeline Server di tab Status halaman layanan YARN.

   Item konfigurasi	Nilai	Deskripsi
   yarn.timeline-service.store-class	org.apache.hadoop.yarn.server.timeline.RollingLevelDBTimelineStore	Menentukan kelas penyimpanan peristiwa YARN Timeline Server.
   yarn.timeline-service.rolling-period	daily	Menentukan periode rolling peristiwa YARN Timeline Server.
   yarn.timeline-service.leveldb-timeline-store.read-cache-size	4.194.304	Menentukan ukuran cache baca dari YARN Timeline Server LevelDB store.
   yarn.timeline-service.leveldb-timeline-store.write-buffer-size	4.194.304	Menentukan ukuran buffer tulis dari YARN Timeline Server LevelDB store.
   yarn.timeline-service.leveldb-timeline-store.max-open-files	500	Menentukan jumlah maksimum file yang dapat dibuka di YARN Timeline Server LevelDB store.