E-MapReduce：FAQ

Apa yang terjadi selama restart kluster stateful?

Restart kluster stateful mencakup restart ResourceManager dan restart NodeManager. ResourceManager mempertahankan informasi dasar dan status aplikasi, sedangkan NodeManager mempertahankan informasi dan status container yang sedang berjalan. Kedua komponen tersebut secara terus-menerus menyinkronkan statusnya ke sistem penyimpanan eksternal seperti Apache ZooKeeper, LevelDB, dan Hadoop Distributed File System (HDFS).

Setelah restart, status tersebut dimuat ulang dan dipulihkan secara otomatis sehingga aplikasi dan container dapat dilanjutkan tanpa gangguan. Dalam sebagian besar kasus, upgrade atau restart kluster tidak terasa oleh aplikasi dan container yang sedang berjalan.

Bagaimana cara mengaktifkan high availability (HA) ResourceManager?

Pada tab Configure halaman layanan YARN di konsol EMR, centang atau atur parameter-parameter berikut:

Bagaimana cara memeriksa apakah layanan ResourceManager normal?

Terdapat tiga metode, diurutkan dari yang paling sederhana hingga paling menyeluruh:

1. Periksa status HA ResourceManager. Di kluster HA, tepat satu proses ResourceManager harus dalam status Active. Verifikasi bahwa haState bernilai ACTIVE atau STANDBY dan bahwa haZooKeeperConnectionState bernilai CONNECTED.

• Command-line interface (CLI): Jalankan yarn rmadmin -getAllServiceState.

• RESTful API: Akses http://<rmAddress>/ws/v1/cluster/info.

2. Periksa status aplikasi YARN. Jalankan yarn application -list dan cari aplikasi yang terjebak dalam status SUBMITTED atau ACCEPTED.

3. Kirim aplikasi uji. Pastikan aplikasi baru dapat dijalankan dan diselesaikan:

hadoop jar <hadoop_home>/share/hadoop/mapreduce/hadoop-mapreduce-client-jobclient-*-tests.jar sleep -m 1 -mt 1000 -r 0

Untuk mengirim ke antrian tertentu, tambahkan -Dmapreduce.job.queuename di antara sleep dan -m. Antrian default adalah default.

Parameter apa saja yang mengontrol sumber daya maksimum untuk satu task atau container?

Sumber daya maksimum per task atau container bergantung pada pengaturan penjadwal tingkat kluster dan tingkat antrian:

Jika permintaan melebihi batas maksimum, pengecualian InvalidResourceRequestException: Invalid resource request... muncul di log aplikasi.

Apa yang harus saya lakukan jika perubahan konfigurasi YARN tidak berlaku?

Berkas konfigurasi yang berbeda memerlukan tindakan lanjutan yang berbeda:

Contoh restart komponen:

• Restart ResourceManager setelah mengubah YARN_RESOURCEMANAGER_HEAPSIZE di yarn-env.sh atau yarn.resourcemanager.nodes.exclude-path di yarn-site.xml.

• Restart NodeManager setelah mengubah YARN_NODEMANAGER_HEAPSIZE di yarn-env.sh atau yarn.nodemanager.log-dirs di yarn-site.xml.

• Restart MRHistoryServer setelah mengubah MAPRED_HISTORYSERVER_OPTS di mapred-env.sh atau mapreduce.jobhistory.http.policys di mapred-site.xml.

Bagaimana cara mengonfigurasi hot update?

Langkah 1: Atur parameter kunci.

Pada tab Configure halaman layanan YARN di konsol EMR:

Langkah 2: Lihat konfigurasi penjadwal saat ini.

• RESTful API: Akses http://<rm-address>/ws/v1/cluster/scheduler-conf.

• HDFS: Telusuri ${yarn.scheduler.configuration.fs.path}/capacity-scheduler.xml.<timestamp>. Berkas dengan timestamp terbesar adalah konfigurasi terbaru.

Langkah 3: Perbarui konfigurasi melalui API.

Contoh: ubah yarn.scheduler.capacity.maximum-am-resource-percent dan hapus yarn.scheduler.capacity.xxx (hapus field nilai untuk menghapus parameter):

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 suatu antrian?

Pekerjaan besar sering kali menghabiskan semua sumber daya dalam suatu antrian, sehingga pekerjaan kecil kelaparan. Dua perubahan berikut mengatasi masalah ini:

1. Ganti kebijakan pengurutan antrian dari FIFO ke fair.

Ubah yarn.scheduler.capacity.<queue-path>.ordering-policy dari default fifo menjadi fair.

Penjadwal First In, First Out (FIFO) dan penjadwal fair adalah dua jenis penjadwal di YARN.

Secara opsional, atur yarn.scheduler.capacity.<queue-path>.ordering-policy.fair.enable-size-based-weight. Nilai default adalah false, yang mengurutkan pekerjaan berdasarkan penggunaan sumber daya secara ascending. Atur ke true untuk mengurutkan berdasarkan hasil bagi antara penggunaan sumber daya dan permintaan sumber daya secara ascending.

2. Aktifkan preemption sumber daya intra-antrian.

Preemption sumber daya antar-antrian diaktifkan secara default dan tidak dapat dinonaktifkan. Untuk juga mengaktifkan preemption intra-antrian, konfigurasikan parameter-parameter berikut:

Bagaimana cara melihat penggunaan sumber daya suatu antrian?

Periksa metrik Used Capacity pada UI web YARN. Used Capacity adalah persentase sumber daya yang dikonsumsi oleh suatu antrian relatif terhadap semua sumber daya yang dialokasikan ke antrian tersebut. Persentase sumber daya memori dan persentase vCores dihitung secara terpisah. Nilai yang lebih tinggi menjadi nilai Used Capacity.

Untuk melihatnya:

1. Buka UI web YARN. Untuk detailnya, lihat Akses UI web komponen open source.

2. Pada halaman All Applications, klik ID pekerjaan tertentu.

3. Klik antrian yang diinginkan pada baris Queue.

4. Pada bagian Application Queues, lihat penggunaan sumber daya.

Bagaimana cara mendapatkan status aplikasi?

Bagaimana cara melakukan troubleshooting masalah aplikasi?

Ikuti alur kerja progresif berikut:

Langkah 1: Periksa status aplikasi.

Lihat status pada halaman detail aplikasi atau melalui RESTful API (http://<rmAddress>/ws/v1/cluster/apps/<applicationId>). Lakukan diagnosis berdasarkan status:

Status Unknown:

Aplikasi gagal sebelum dikirim ke YARN atau tidak dapat mencapai ResourceManager.

• Periksa log pengiriman aplikasi untuk masalah pada komponen klien seperti BRS dan FlowAgent.

• Jika koneksi jaringan abnormal, kesalahan berikut muncul di klien:

    com.aliyun.emr.flow.agent.common.exceptions.EmrFlowException: ###[E40001,RESOURCE_MANAGER]: Failed to access to resource manager, cause: The stream is closed

NEW_SAVING:

Informasi aplikasi sedang ditulis ke penyimpanan status ZooKeeper. Jika terjebak di sini, periksa apakah ZooKeeper dalam kondisi sehat. Untuk kesalahan baca/tulis ZooKeeper, lihat Apa yang harus saya lakukan jika ResourceManager tidak dapat beralih dari Standby ke Active?

SUBMITTED:

Langka dalam kondisi normal. Di kluster besar, kontensi lock di Capacity Scheduler dapat menyebabkan hal ini. Lihat YARN-9618 untuk detail optimasi.

ACCEPTED -- periksa pesan diagnostik:

RUNNING:

Jika aplikasi sedang berjalan tetapi tampak macet, lanjutkan ke Langkah 2 untuk memeriksa apakah permintaan sumber daya container tertunda.

FAILED -- periksa pesan diagnostik:

Langkah 2: Verifikasi apakah alokasi sumber daya YARN tertunda.

1. Pada halaman daftar aplikasi, klik ID aplikasi.

2. Pada halaman detail aplikasi, klik ID upaya aplikasi.

3. Periksa daftar Total Outstanding Resource Requests untuk sumber daya yang tertunda. Anda juga dapat mengkueri sumber daya yang tertunda melalui RESTful API untuk permintaan yang tertunda.

   • Jika tidak ada sumber daya yang tertunda, alokasi sumber daya YARN telah selesai. Keluar dari alur kerja ini dan periksa alokasi sumber daya AM.

   • Jika ada sumber daya yang tertunda, lanjutkan ke Langkah 3.

Langkah 3: Periksa batas sumber daya.

Periksa sumber daya kluster dan antrian, khususnya nilai Effective Max Resource dan Used Resources.

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

2. Periksa apakah dimensi sumber daya apa pun dalam antrian leaf mendekati atau mencapai batas atasnya.

3. Jika penggunaan sumber daya kluster mendekati 100%, misalnya lebih dari 85%, kecepatan alokasi sumber daya ke aplikasi dapat menurun. Dua alasan umum:

   • Sebagian besar mesin tidak memiliki sumber daya yang tersedia, menyebabkan reservasi. Ketika cukup banyak mesin dicadangkan, kecepatan alokasi menurun.

   • Sumber daya memori dan CPU tidak seimbang di seluruh mesin. Beberapa mesin memiliki memori idle tetapi tidak memiliki CPU idle, dan sebaliknya.

Langkah 4: Periksa apakah container yang dialokasikan gagal dimulai.

Pada halaman App Attempt di UI web YARN, amati jumlah container yang dialokasikan dan perubahan dalam periode singkat. Jika container gagal dimulai, lakukan troubleshooting dari log NodeManager atau log container.

Langkah 5: Aktifkan logging tingkat debug untuk investigasi lebih dalam.

Pada halaman Log Level di UI web YARN di http://RM_IP:8088/logLevel, ubah tingkat log untuk org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity menjadi DEBUG.

Apa yang harus saya lakukan jika ResourceManager tidak dapat beralih dari Standby ke Active?

Pertama, verifikasi parameter HA. Tiga parameter berikut harus semuanya bernilai true:

Jika parameter tersebut sudah benar, selidiki ZooKeeper:

• Periksa apakah ZooKeeper dalam kondisi sehat.

• Luapan buffer klien ZooKeeper. Log ResourceManager berisi Zookeeper error len*** is out of range! atau Unreasonable length = ***. Perbaikan: Pada tab Configure halaman layanan YARN di konsol EMR, klik tab yarn-env dan atur yarn_resourcemanager_opts ke -Djute.maxbuffer=4194304. Restart ResourceManager.

• Luapan buffer server ZooKeeper. Log ZooKeeper berisi Exception causing close of session 0x1000004d5701b6a: Len error ***. Perbaikan: Tambahkan atau perbarui parameter -Djute.maxbuffer= untuk setiap node ZooKeeper untuk meningkatkan batas buffer (satuan: byte).

• Node ephemeral ZooKeeper macet. Jika log ResourceManager maupun ZooKeeper tidak menunjukkan pengecualian, periksa apakah node ephemeral pemilihan leader ditempati oleh sesi usang. Jalankan perintah stat di CLI ZooKeeper pada node di ${yarn.resourcemanager.zk-state-store.parent-path}/${yarn.resourcemanager.cluster-id}/ActiveStandbyElectorLock. Perbaikan: Beralih ke pemilihan leader berbasis Curator. Pada tab yarn-site, tambahkan atau atur yarn.resourcemanager.ha.curator-leader-elector.enabled ke true. Restart ResourceManager.

Apa yang harus saya lakukan jika terjadi masalah out of memory (OOM) di ResourceManager?

Identifikasi jenis OOM dari log ResourceManager.

Kesalahan: Java heap space, GC overhead limit exceeded, atau garbage collection (GC) penuh berulang

Memori heap mesin virtual Java (JVM) habis. ResourceManager menyimpan banyak objek resident di memori: kluster, antrian, aplikasi, container, dan node. Memori heap yang dikonsumsi objek-objek ini bertambah seiring ukuran kluster. Data aplikasi historis juga terakumulasi seiring waktu. Bahkan kluster satu node mengonsumsi memori untuk data historis. Memori heap minimum yang direkomendasikan untuk ResourceManager: 2 GB.

Perbaikan:

• Tingkatkan memori heap dengan mengubah YARN_RESOURCEMANAGER_HEAPSIZE di yarn-env.sh.

• Kurangi aplikasi historis yang disimpan dengan mengubah yarn.resourcemanager.max-completed-applications di yarn-site.xml (default: 10000).

Kesalahan: unable to create new native thread

Node yang menjalankan ResourceManager telah mencapai batas thread sistem. Jumlah maksimum thread bergantung pada batas per pengguna dan batas identifier proses sistem (PID).

Periksa batas-batas tersebut:

ulimit -a | grep "max user processes"
cat /proc/sys/kernel/pid_max

Temukan 10 proses teratas berdasarkan jumlah thread:

ps -eLf | awk '{print $2}' | uniq -c | awk '{print $2"\t"$1}' | sort -nrk2 | head

Output menunjukkan [ID Proses] [Jumlah Thread].

Perbaikan:

• Jika batas thread atau PID terlalu rendah, tingkatkan di pengaturan sistem. Node spesifikasi kecil biasanya membutuhkan puluhan ribu; node spesifikasi besar membutuhkan ratusan ribu.

• Jika batas sudah wajar, selidiki proses yang paling banyak mengonsumsi thread.

Apa yang harus saya lakukan jika muncul kesalahan ketidakcocokan versi RPC?

Pesan kesalahan Exception while invoking getClusterNodes...Trying to fail over immediately menunjukkan ResourceManager aktif tidak dapat diakses. Log ResourceManager berisi:

WARN org.apache.hadoop.ipc.Server: Incorrect header or version mismatch from 10.33.**.**:53144 got version 6 expected version 9

Versi Hadoop yang lama sedang digunakan. Versi remote procedure call (RPC) yang digunakan oleh klien aplikasi tidak kompatibel dengan versi Hadoop di kluster.

Perbaikan: Gunakan versi Hadoop yang kompatibel dengan versi RPC klien aplikasi.

Mengapa lokalitas gagal saat node memulai pekerjaan, dan mengapa log pekerjaan tidak dapat dikumpulkan atau dihapus?

Log NodeManager berisi:

java.io.IOException: Couldn't create proxy provider class org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider

Konfigurasi HDFS salah. Pengecualian ini adalah pembungkus, bukan akar permasalahan. Aktifkan logging tingkat debug untuk menemukan masalah sebenarnya:

• Di CLI klien Hadoop, jalankan perintah seperti hadoop fs -ls /, lalu aktifkan debugging:

    export HADOOP_LOGLEVEL=DEBUG

• Di lingkungan runtime dengan Log4j, tambahkan baris ini ke konfigurasi Log4j:

    log4j.logger.org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider=DEBUG

Akar permasalahan umum: konfigurasi NameServices diubah (misalnya, emr-cluster diubah menjadi hadoop-emr-cluster), tetapi node baru dari scale-out masih menggunakan konfigurasi NameServices asli.

Perbaikan: Pada tab Configure halaman layanan HDFS di konsol EMR, verifikasi bahwa parameter telah dikonfigurasi dengan benar.

Bagaimana cara menangani pengecualian lokalitas sumber daya?

Gejala:

• Container AM gagal dimulai dengan diagnosis berikut:

    Application application_1412960082388_788293 failed 2 times due to AM Container for appattempt_1412960082388_788293_000002 exited with exitCode: -1000 due to: EPERM: Operation not permitted

• Log NodeManager menunjukkan kesalahan saat mendekompresi paket sumber daya yang diunduh:

    INFO org.apache.hadoop.yarn.server.nodemanager.containermanager.localizer.ResourceLocalizationService: Failed to download 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: Operation not permitted
            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)
            ...

Paket sumber daya aplikasi berisi soft link, yang menyebabkan operasi chmod gagal.

Perbaikan: Hapus soft link dari paket sumber daya aplikasi.

Apa yang harus saya lakukan jika muncul kesalahan "No space left on device" dan container gagal dimulai atau dijalankan?

Periksa penyebab-penyebab berikut secara berurutan:

1. Ruang disk. Verifikasi bahwa disk memiliki ruang yang tersedia.

2. Pengaturan cgroups cgroup.clone_children. Periksa nilai di /sys/fs/cgroup/cpu/hadoop-yarn/ dan /sys/fs/cgroup/cpu/.

   • Jika cgroup.clone_children bernilai 0, ubah menjadi 1: ``bash echo 1 > /sys/fs/cgroup/cpu/cgroup.clone_children ``

   • Jika masalah berlanjut, periksa berkas cpuset.mems atau cpuset.cpus di direktori tingkat yang sama. Nilai di direktori hadoop-yarn harus sesuai dengan nilai di direktori tingkat atas.

3. Batas subdirektori cgroups. Periksa apakah jumlah subdirektori di bawah direktori cgroups melebihi batas atas 65.535. Untuk memeriksa, temukan berkas konfigurasi YARN dan lihat parameter yarn.nodemanager.linux-container-executor.cgroups.delete-delay-ms atau yarn.nodemanager.linux-container-executor.cgroups.delete-timeout-ms.

Resolusi nama domain gagal di NodeManager atau selama eksekusi pekerjaan. Apa yang harus saya lakukan?

Pesan kesalahan:

java.net.UnknownHostException: Invalid host name: local host is: (unknown)

Periksa penyebab-penyebab berikut secara berurutan:

1. DNS configuration. Verifikasi bahwa server Domain Name System (DNS) dikonfigurasi dengan benar:

      cat /etc/resolv.conf

2. Aturan firewall. Periksa apakah aturan yang diperlukan telah dikonfigurasi untuk Port 53. Jika aturan telah dikonfigurasi, nonaktifkan firewall.

3. Layanan NSCD. Periksa apakah Name Service Cache Daemon (NSCD) sedang berjalan: Jika NSCD sedang berjalan, hentikan:

      systemctl status nscd

      systemctl stop nscd

Apa yang harus saya lakukan jika terjadi masalah OOM di NodeManager?

Identifikasi jenis OOM dari log NodeManager.

Kesalahan: Java heap space, GC overhead limit exceeded, atau GC penuh berulang

NodeManager memiliki sedikit objek resident (node saat ini, aplikasi, dan container), tetapi cache dan buffer layanan shuffle eksternal dapat mengonsumsi memori heap yang signifikan. Parameter terkait meliputi:

• Spark: spark.shuffle.service.index.cache.size, spark.shuffle.file.buffer

• MapReduce: mapreduce.shuffle.ssl.file.buffer.size, mapreduce.shuffle.transfer.buffer.size

Memori heap yang dikonsumsi oleh layanan shuffle sebanding dengan jumlah aplikasi dan container yang menggunakannya. Node yang lebih besar dengan lebih banyak task memerlukan lebih banyak memori. Memori heap minimum yang direkomendasikan untuk NodeManager: 1 GB.

Perbaikan:

• Tingkatkan memori heap dengan mengubah YARN_NODEMANAGER_HEAPSIZE di yarn-env.sh.

• Periksa apakah pengaturan cache layanan shuffle wajar. Misalnya, cache shuffle Spark tidak boleh mengonsumsi sebagian besar heap.

Kesalahan: Direct buffer memory

Memori off-heap meluap, biasanya disebabkan oleh layanan shuffle eksternal yang menggunakan NIO DirectByteBuffer untuk RPC.

Konsumsi memori off-heap sebanding dengan jumlah aplikasi dan container yang menggunakan layanan shuffle. Untuk node yang menjalankan banyak task intensif shuffle, alokasi memori off-heap mungkin terlalu kecil.

Perbaikan: Periksa nilai XX:MaxDirectMemorySize di YARN_NODEMANAGER_OPTS di yarn-env.sh. Jika tidak dikonfigurasi, ukuran memori off-heap default sama dengan ukuran memori heap. Tingkatkan nilai tersebut jika terlalu kecil.

Kesalahan: unable to create new native thread

Akar penyebab dan solusi sama dengan masalah thread OOM ResourceManager. Lihat Apa yang harus saya lakukan jika terjadi masalah OOM di ResourceManager?

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

Pesan kesalahan:

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

Instance ECS di-restart secara abnormal, kemungkinan besar karena cacat kernel. Ini adalah masalah yang diketahui pada versi kernel 4.19.91-21.2.al7.x86_64. Setelah restart, data cgroups di memori dihapus, sehingga cgroups tidak valid.

Perbaikan: Tambahkan skrip bootstrap ke grup node Anda yang membuat direktori cgroups saat startup dan mempertahankannya melalui rc.local:

# enable cgroups
mkdir -p /sys/fs/cgroup/cpu/hadoop-yarn
chown -R hadoop:hadoop /sys/fs/cgroup/cpu/hadoop-yarn
# enable cgroups after 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 saya lakukan jika konfigurasi sumber daya NodeManager tidak berlaku setelah disimpan dan di-restart?

Parameter yarn.nodemanager.resource.cpu-vcores dan yarn.nodemanager.resource.memory-mb telah diubah dan disimpan, tetapi perubahan tidak berlaku setelah NodeManager di-restart.

Jumlah core CPU dan ukuran memori dapat bervariasi di seluruh instance dalam grup node. Parameter-parameter ini harus diatur pada tingkat grup node, bukan tingkat kluster.

Perbaikan: Di konsol EMR, buka tab Configure halaman layanan YARN. Pilih Node Group Configuration dari daftar drop-down di sebelah kotak pencarian. Pilih grup node tempat NodeManager berada. Kemudian ubah yarn.nodemanager.resource.cpu-vcores dan yarn.nodemanager.resource.memory-mb. Untuk detailnya, lihat Kelola item konfigurasi.

Apa yang harus saya lakukan jika node ditandai sebagai unhealthy?

Dua kemungkinan penyebab:

1. Kegagalan pemeriksaan kesehatan disk. Jika rasio direktori sehat terhadap total direktori di node turun di bawah yarn.nodemanager.disk-health-checker.min-healthy-disks (default: 0,25), node ditandai sebagai unhealthy. Untuk node dengan empat disk, keempat disk harus memiliki direktori abnormal sebelum node ditandai sebagai unhealthy. Jika tidak, laporan hanya menunjukkan "local-dirs are bad" atau "log-dirs are bad". Lihat Apa yang harus saya lakukan jika muncul "local-dirs are bad" atau "log-dirs are bad"?

2. Skrip pemeriksaan kesehatan NodeManager. Secara default, skrip ini dinonaktifkan. Aktifkan dengan mengonfigurasi yarn.nodemanager.health-checker.script.path di yarn-site.xml. Jika skrip ini mendeteksi masalah, selesaikan masalah tersebut berdasarkan logika skrip kustom.

Apa yang harus saya lakukan jika muncul "local-dirs are bad" atau "log-dirs are bad"?

Pemeriksaan kesehatan disk (diaktifkan secara default) secara berkala memeriksa apakah local-dirs (direktori cache task untuk file dan data antara) dan log-dirs (direktori log task) memenuhi kondisi-kondisi berikut:

• Dapat dibaca

• Dapat ditulis

• Dapat dieksekusi

• Penggunaan disk di bawah yarn.nodemanager.disk-health-checker.max-disk-utilization-per-disk-percentage (default: 90%)

• Ruang disk yang tersedia melebihi yarn.nodemanager.disk-health-checker.min-free-space-per-disk-mb (default: 0)

Jika salah satu kondisi tidak terpenuhi, direktori tersebut ditandai sebagai buruk.

Perbaikan:

• Ruang disk tidak mencukupi (paling umum). Perluas disk jika salah satu kondisi berikut berlaku: node memiliki spesifikasi tinggi dengan banyak task, ruang disk kecil, data task atau data antara besar, atau log task besar.

• Cache terlalu besar. Periksa yarn.nodemanager.localizer.cache.target-size-mb di yarn-site.xml. Jika rasio cache terhadap disk terlalu tinggi, data task yang di-cache menempati sebagian besar disk karena cache hanya dibersihkan saat ambang batas terlampaui.

• Disk rusak. Lihat Ganti disk lokal yang rusak untuk kluster EMR.

Mengapa sejumlah besar berkas log .out terakumulasi untuk komponen layanan YARN?

Pustaka dependensi Hadoop tertentu memanggil API logging Java alih-alih Log4j, sehingga tidak mendukung rotasi log. Output error standar (stderr) komponen daemon dialihkan ke berkas log .out. Tanpa mekanisme pembersihan otomatis, log-log ini terakumulasi dan dapat mengisi disk data.

Perbaikan: Gunakan perintah head dan tail dengan informasi timestamp di log untuk mengidentifikasi log API logging Java mana yang paling banyak mengonsumsi ruang. Dalam sebagian besar kasus, ini adalah log tingkat INFO dari pustaka dependensi yang tidak memengaruhi fungsi komponen. Nonaktifkan pembuatan log tingkat INFO untuk paket yang bermasalah.

Contoh: Nonaktifkan pembuatan log Jersey untuk Timeline Server.

1. Monitor berkas log .out untuk timelineserver- di direktori log YARN. Output berisi catatan yang dihasilkan oleh paket com.sun.jersey.

   • Path kluster DataLake: /var/log/emr/yarn/

   • Path kluster Hadoop: /mnt/disk1/log/hadoop-yarn

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

2. Di node Timeline Server, buat berkas konfigurasi sebagai root untuk menonaktifkan logging Jersey:

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

3. Pada tab Configure halaman layanan YARN di konsol EMR, temukan YARN_TIMELINESERVER_OPTS (atau yarn_timelineserver_opts di kluster Hadoop). Tambahkan ini ke nilai:

      -Djava.util.logging.config.file=off-logging.properties

4. Simpan konfigurasi dan restart Timeline Server. Jika Timeline Server dimulai secara normal dan berkas log .out tidak lagi berisi entri com.sun.jersey, perbaikan berhasil.

Apa yang harus saya lakukan jika muncul kesalahan "User [dr.who] is not authorized to view the logs for application"?

Aturan daftar kontrol akses (ACL) diperiksa saat mengakses halaman Log NodeManager. Jika aturan ACL diaktifkan, pengguna jarak jauh harus memenuhi salah satu kondisi berikut untuk melihat log aplikasi:

• Pengguna jarak jauh adalah pengguna admin.

• Pengguna jarak jauh adalah pemilik aplikasi.

• Pengguna jarak jauh memenuhi aturan ACL yang dikustomisasi untuk aplikasi tersebut.

Perbaikan: Verifikasi bahwa pengguna jarak jauh memenuhi salah satu kondisi tersebut.

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

YARN menggunakan autentikasi simple dan secara default tidak mengizinkan akses anonim. Lihat Autentikasi untuk konsol web HTTP Hadoop.

Perbaikan:

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

• Metode 2: Di bagian Configuration Filter pada tab Configure halaman layanan HDFS di konsol EMR, cari hadoop.http.authentication.simple.anonymous.allowed dan atur ke true untuk mengizinkan akses anonim. Kemudian restart layanan HDFS. Untuk detailnya, lihat Restart layanan.

Mengapa nilai tampilan TotalVcore salah?

Di bagian kluster atau metrik RESTful API di UI web YARN (pojok kanan atas), nilai TotalVcore mungkin salah. Ini adalah bug logika komputasi di versi Apache Hadoop sebelum 2.9.2. Lihat YARN-8443.

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

Apa yang harus saya lakukan jika informasi aplikasi di UI web Tez tidak lengkap?

Buka Developer tools browser Anda dan periksa permintaan mana yang gagal:

1. Permintaan ke http://<rmAddress>/ws/v1/cluster/apps/APPID gagal. ResourceManager telah menghapus data aplikasi. Secara default, ResourceManager menyimpan informasi untuk maksimal 1.000 aplikasi. Aplikasi yang melebihi batas ini dihapus berdasarkan urutan mulainya.

2. Permintaan ke http://<tsAddress>/ws/v1/applicationhistory/... mengembalikan kode kesalahan 500 (aplikasi tidak ditemukan). Informasi aplikasi gagal disimpan atau dihapus oleh penyimpanan Timeline.

   • Periksa yarn.resourcemanager.system-metrics-publisher.enabled untuk menentukan apakah penyimpanan gagal.

   • Periksa masa hidup data (TTL) LevelDB untuk menentukan apakah data dihapus.

3. Permintaan ke http://<tsAddress>/ws/v1/timeline/... mengembalikan kode 200 tetapi menampilkan NotFound. Periksa output inisialisasi syslog AM. Inisialisasi normal terlihat seperti: Jika peringatan berikut muncul, yarn.timeline-service.enabled diatur ke false untuk AM yang sedang berjalan. Penyebab yang mungkin adalah masalah FlowAgent. Pekerjaan Hive yang diimplementasikan melalui FlowAgent (menggunakan perintah Hive atau perintah Beeline) memiliki yarn.timeline-service.enabled diatur ke false secara default di FlowAgent.

      [INFO] [main] |history.HistoryEventHandler|: Initializing HistoryEventHandler withrecoveryEnabled=true, historyServiceClassName=org.apache.tez.dag.history.logging.ats.ATSHistoryLoggingService
      [INFO] [main] |ats.ATSHistoryLoggingService|: Initializing ATSHistoryLoggingService with maxEventsPerBatch=5, maxPollingTime(ms)=10, waitTimeForShutdown(ms)=-1, TimelineACLManagerClass=org.apache.tez.dag.history.ats.acls.ATSHistoryACLPolicyManager

      [WARN] [main] |ats.ATSHistoryLoggingService|: org.apache.tez.dag.history.logging.ats.ATSHistoryLoggingService is disabled due to Timeline Service being disabled, yarn.timeline-service.enabled set to false

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

Jika Anda memilih Spark saat membuat kluster, layanan Spark Thrift Server default dimulai secara otomatis. Layanan ini menempati satu sumber daya driver YARN. Secara default, task yang berjalan di Spark Thrift Server meminta sumber daya 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 Object Storage Service (OSS).

Di kluster Hadoop, nilai default yarn.timeline-service.leveldb-timeline-store.path sama dengan nilai hadoop.tmp.dir. Jangan ubah hadoop.tmp.dir, karena perubahan akan memengaruhi yarn.timeline-service.leveldb-timeline-store.path.

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

Dengan sejumlah besar pekerjaan Apache Tez, penulisan data ke Timeline Server dapat timeout karena proses Timeline Server mengonsumsi sumber daya CPU berlebihan dan beban CPU di nodenya mencapai batas atas. Hal ini dapat memengaruhi pengembangan pekerjaan dan layanan non-inti seperti pembuatan laporan.

Sebagai tindakan segera, hentikan proses Timeline Server untuk mengurangi beban CPU node. Kemudian terapkan perubahan konfigurasi berikut:

Langkah 1: Atur timeout flush event Tez.

Pada tab tez-site.xml di tab Configure halaman layanan Tez di konsol EMR, tambahkan item konfigurasi:

• Nama: tez.yarn.ats.event.flush.timeout.millis

• Nilai: 60000

Ini mengatur timeout untuk pekerjaan Tez yang menulis event ke Timeline Server.

Langkah 2: Optimalkan penyimpanan Timeline Server.

Pada tab yarn-site.xml di tab Configure halaman layanan YARN di konsol EMR, tambahkan atau ubah item konfigurasi berikut:

Setelah melakukan perubahan ini, restart Timeline Server di tab Status halaman layanan YARN. Untuk detail tentang pengelolaan konfigurasi, lihat Kelola item konfigurasi.