14. オリジナルスライドの発表者
• Kate Ting
o Customer Operations Engineer, Cloudera
o 9 ヶ月で100以上のHadoopクラスタのトラブルシュー
ティングに携わってきた
o [email protected]
• Ariel Rabkin
o Customer Operations Tools Team, Cloudera(インター
ン)
o UC Berkeley CS PhD 候補生
o 設定バグの診断に関する論文
o [email protected]
16. Agenda
• チケット分析
• 設定ミスとは?
• メモリの管理ミス
• TT OOME
• JT OOME
• Native Threads
• スレッドの管理ミス
• Fetch Failures
• Replicas
• ディスクの管理ミス
• No File
• Too Many Files
• Cloudera Manager
17. 1. Task Out Of Memory Error
FATAL org.apache.hadoop.mapred.TaskTracker:
Error running child : java.lang.OutOfMemoryError: Java heap space
at
org.apache.hadoop.mapred.MapTask$MapOutputBuffer.<init>(MapTask
.java:781)
at
org.apache.hadoop.mapred.MapTask.runOldMapper(MapTask.java:350
)
at org.apache.hadoop.mapred.MapTask.run(MapTask.java:307)
at org.apache.hadoop.mapred.Child.main(Child.java:170)
18. 1. Task Out Of Memory Error
• どういう意味?
o タスクのコード内でメモリリークが発生している
• 何が原因?
o MR タスクのヒープサイズが合わない
• どうすれば解決できる?
o io.sort.mb < mapred.child.java.opts となるように設定
o 例 io.sort.mb を 512M にしたら mapred.child.java.opts は 1G にする
io.sort.mb = map バッファのサイズ
バッファが小さくなる => ディスクへの書き出しが多くな
る
o mapper と reducer を減らす
mapper = ノード上のコア数
HBase を使っていない場合
ディスク数とコア数が同じ場合
mapper:reducer 比は 4:3
19. (Mappers + Reducers)*
Child Task Heap
+
DN heap
+
Total RAM TT heap
+
3GB
+
RS heap
+
Other Services' heap
RS: Region Server
20. 2. JobTracker Out of Memory Error
ERROR org.apache.hadoop.mapred.JobTracker: Job initialization failed:
java.lang.OutOfMemoryError: Java heap space
at org.apache.hadoop.mapred.TaskInProgress.<init>(TaskInProgress.java:122)
at org.apache.hadoop.mapred.JobInProgress.initTasks(JobInProgress.java:653)
at org.apache.hadoop.mapred.JobTracker.initJob(JobTracker.java:3965)
at
org.apache.hadoop.mapred.EagerTaskInitializationListener$InitJob.run(EagerTaskIniti
alizationListener.java:79)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:8
86)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
21. 2. JobTracker Out of Memory Error
• どういう意味?
o JT のメモリ使用量の合計 > 割り当て RAM
• 何が原因?
o タスクが小さすぎ
o job ヒストリが多すぎ
22. 2. JobTracker Out of Memory Error
• どうすれば解決できる?
o サマリーの出力によって確認可能
o sudo -u mapred jmap -J-d64 -histo:live <PID of JT>
o JT のヒープ領域を増やす
o JT と NN のノードを分ける
o mapred.jobtracker.completeuserjobs.maximum を 5 に
減らす
JT はメモリをより頻繁にクリンナップするようにな
り、必要な RAM が減る
23. 3. Unable to Create New Native Thread
ERROR mapred.JvmManager: Caught Throwable in JVMRunner. Aborting
TaskTracker.
java.lang.OutOfMemoryError: unable to create new native thread
at java.lang.Thread.start0(Native Method)
at java.lang.Thread.start(Thread.java:640)
at org.apache.hadoop.util.Shell.runCommand(Shell.java:234)
at org.apache.hadoop.util.Shell.run(Shell.java:182)
at org.apache.hadoop.util.Shell$ShellCommandExecutor.execute(Shell.java:375)
at
org.apache.hadoop.mapred.DefaultTaskController.launchTask(DefaultTaskController.j
ava:127)
at
org.apache.hadoop.mapred.JvmManager$JvmManagerForType$JvmRunner.runChild
(JvmManager.java:472)
at
org.apache.hadoop.mapred.JvmManager$JvmManagerForType$JvmRunner.run(Jvm
Manager.java:446)
24. 3. Unable to Create New Native Thread
• どういう意味?
o プロセスが起動中にもかかわらず DN が障害ノードと
して表示されている
• 何が原因?
o nproc のデフォルト値は低すぎ
• どうすれば解決できる?
o /etc/security/limits.conf を修正する
hbase soft/hard nproc 50000
hdfs soft/hard nproc 50000
mapred soft/hard nproc 50000
o その後 DN,TT,JT,NN を再起動
25. Agenda
• チケット分析
• 設定ミスとは?
• メモリの管理ミス
• TT OOME
• JT OOME
• Native Threads
• スレッドの管理ミス
• Fetch Failures
• Replicas
• ディスクの管理ミス
• No File
• Too Many Files
• Cloudera Manager
26. 4. Too Many Fetch-Failures
INFO org.apache.hadoop.mapred.JobInProgress: Too many
fetch-failures for output of task:
27. 4. Too Many Fetch-Failures
• どういう意味?
o Reducer の fetch 操作が mapper 出力の取得に失敗して
いる
o Too many fetch failures は特定の TT( = ブラックリスト
入りの TT) で発生する
• 何が原因?
o DNS の問題
o mapper 側に十分な reducer 用 http スレッドがない
o JVM のバグ
28. 4. Too Many Fetch-Failures
• どうすれば解決できる?
o mapred.reduce.slowstart.completed.maps = 0.80
大きいジョブがたくさんの reducer を wait 状態にし続けない
ようにする
o tasktracker.http.threads = 80
map 出力を reducer に供給するために TT に使用されるス
レッド数を大きくする
o mapred.reduce.parallel.copies = SQRT(ノード数) して一の位を
切り下げ(例: 500ノード→20, 1000ノード→30)
map 出力を取得するために reducer に使用される並列コピー
の数を指定する
o Jetty 6.1.26 は fetch failure を起こしやすいので使わない
o CDH3u2 に上げましょう (MAPREDUCE-2980)
o CDH3u3 では jetty バグの自動検知も可能に(MAPREDUCE-3184)
29. 5. Not Able to Place Enough Replicas
WARN org.apache.hadoop.hdfs.server.namenode.FSNamesystem: Not
able to place enough replicas
30. 5. Not Able to Place Enough Replicas
• どういう意味?
o NN が一部の DN を選択できない
31. 5. Not Able to Place Enough Replicas
• 何が原因?
o dfs のレプリケーション数 > 利用可能な DN の数
o ディスク領域不足による 利用可能 DN 数の不足
o mapred.submit.replication のデフォルト値は 10 と高すぎ
o NN がブロック設置ポリシーを満たすことができない
o もしラック数が2より多い場合、ブロックは少なくとも2つの
ラック上に存在していなければならない
o DN がデコミッション中
o DN に高い負荷がかかっている
o ブロックサイズが不必要に大きい
o 十分な xciever スレッドがない
DN が扱えるスレッド数はデフォルト 256 でとても低い
パラメータのスペルミスに注意
32. 5. Not Able to Place Enough Replicas
• どうすれば解決できる?
o dfs.datanode.max.xcievers = 4096 として、DN を再起
動する
o ダウンしてるノードやラックを探す
o ディスク領域を確認する
o log ディレクトリが容量を食っているか、暴走した
タスクがディスクの空きを埋めてるかもしれない
o リバランスしましょう
33. Agenda
• チケット分析
• 設定ミスとは?
• メモリの管理ミス
• TT OOME
• JT OOME
• Native Threads
• スレッドの管理ミス
• Fetch Failures
• Replicas
• ディスクの管理ミス
• No File
• Too Many Files
• Cloudera Manager
34. 6. No Such File or Directory
ERROR org.apache.hadoop.mapred.TaskTracker: Can not start task tracker because
ENOENT: No such file or directory
at org.apache.hadoop.io.nativeio.NativeIO.chmod(Native Method)
at
org.apache.hadoop.fs.RawLocalFileSystem.setPermission(RawLocalFileSystem.java:
496)
at org.apache.hadoop.fs.RawLocalFileSystem.mkdirs(RawLocalFileSystem.java:319)
at org.apache.hadoop.fs.FilterFileSystem.mkdirs(FilterFileSystem.java:189)
at org.apache.hadoop.mapred.TaskTracker.initializeDirectories(TaskTracker.java:666)
at org.apache.hadoop.mapred.TaskTracker.initialize(TaskTracker.java:734)
at org.apache.hadoop.mapred.TaskTracker.<init>(TaskTracker.java:1431)
at org.apache.hadoop.mapred.TaskTracker.main(TaskTracker.java:3521)
36. 6. No Such File or Directory
• どういう意味?
o TT を開始できなかったかジョブが失敗している
• 何が原因?
o TTのディスク領域が埋まっている
o TT が書き込むディレクトリのパーミッション
• どうすれば解決できる?
dfs.datanode.du.reserved をディスク総量の10%にする
ジョブがロギングするディレクトリの容量の確保
userlogs と mapred.local.dirは、パーミッションを
755、オーナーを mapred に設定すること
37. 7. Too Many Open Files
ERROR org.apache.hadoop.hdfs.server.datanode.DataNode: DatanodeRegistration(<ip
address>:50010, storageID=<storage id>, infoPort=50075, ipcPort=50020):DataXceiver
java.io.IOException: Too many open files
at sun.nio.ch.IOUtil.initPipe(Native Method)
at sun.nio.ch.EPollSelectorImpl.<init>(EPollSelectorImpl.java:49)
at sun.nio.ch.EPollSelectorProvider.openSelector(EPollSelectorProvider.java:18)
at org.apache.hadoop.net.SocketIOWithTimeout$SelectorPool.get(SocketIOWithTimeout.java:407)
at org.apache.hadoop.net.SocketIOWithTimeout$SelectorPool.select(SocketIOWithTimeout.java:322)
at org.apache.hadoop.net.SocketIOWithTimeout.doIO(SocketIOWithTimeout.java:157)
at org.apache.hadoop.net.SocketInputStream.read(SocketInputStream.java:155)
at org.apache.hadoop.net.SocketInputStream.read(SocketInputStream.java:128)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
at java.io.BufferedInputStream.read(BufferedInputStream.java:237)
at java.io.DataInputStream.readShort(DataInputStream.java:295)
at org.apache.hadoop.hdfs.server.datanode.DataXceiver.run(DataXceiver.java:97)
38. 7. Too Many Open Files
• どういう意味?
o Hadoop を実行しているユーザアカウントが、開いて
いるファイルディスクリプタ数の制限にひっかかって
いる
• 何が原因?
o nofile のデフォルト値は 1024 ファイルで低すぎ
• どうすれば解決できる?
o /etc/security/limits.conf を修正する
hdfs - nofile 32768
mapred - nofile 32768
hbase - nofile 32768
o その後 DN, TT, JT, NN を再起動
39. Agenda
• チケット分析
• 設定ミスとは?
• メモリの管理ミス
• TT OOME
• JT OOME
• Native Threads
• スレッドの管理ミス
• Fetch Failures
• Replicas
• ディスクの管理ミス
• No File
• Too Many Files
• Cloudera Manager
42. 謝辞
Adam Warrington
Amr Awadallah
Angus Klein
Brock Noland
Clint Heath
Eric Sammer
Esteban Gutierrez
Jeff Bean
Joey Echeverria
Laura Gonzalez
Linden Hillenbrand
Omer Trajman
Patrick Angeles
Kate Ting
Ariel Rabkin
日本語版
Harsh Chouraria
Taka Tazawa
Tatsuo Kawasaki
You are sitting here because you know that misconfigurations and bugs break the most clusters. Fixing bugs is up to the community. Fixing misconfigurations is up to you. I guarantee if you wait an hour before walking out that you will leave with the know-how to get your configuration right the first time.ここに座っている人はほとんどのクラスタの障害が設定ミスによるものであることを知っているはずです。コミュニティはバグを直しますが、設定ミスを直せるのは皆さんだけです。席を立つのをあと30分我慢してくれれば、ここを離れるときには最初にきちんと設定できるノウハウを持っていくことができるでしょう。
hadoop errors show up far from where you configured so don't know what log files to analyzehadoopのエラーはユーザが変更しようとした箇所とはかなり違う場所で発生する。だからユーザはどのログファイルを見ればいいかわからない。
if your cluster is broken, probably a misconfiguration. this is a hard prob b/c the err msgs are not tightly tied to the root causeもしクラスタが壊れていたら、まず設定ミスを疑ってください。でも自分で診断するのは難しいと思う。なぜならエラーメッセージは根本原因ときっちり結びついているわけじゃないから。
ディスクへの書き出しが多くなる-> spill が多くなる
@tlipcon if sum(max heap size) > physical RAM - 3GB, go directly to jail. do not pass go. do not collect $200.もし物理RAMの余りが3GBを切ったら、「刑務所に行け」。GO を通過させちゃいけない。200ドルをゲットさせちゃいけない。という Todd Lipconのツイート。これモノポリーのこと
customer: STE
m.t.c.mCDH, CM3.5 100 by defaultCM3.7 5 by default
why not fix the defaults? b/c they are not static defaults, they are not all hadoop defaults but also OS defaultsなんでデフォルトを直さないのかというと、これはhadoopのデフォルトではなく OS のデフォルト値だから。hbase wiki faq 15 だと 1024 がnprocデフォルトと書かれている
resource allocation is hard because the place where you are misallocating is far from where you ran out e.g. fetch failures could be due to system, config, or bug but not sure what from the error msg and you don't know which misconfig from err msg also ff doesn't show up on the node where it's configuredリソース割り当ては難しい。なぜならユーザが割り当てミスをした場所と、リソースを使い尽くした場所は全く異なる場所になるからだ。fetch failures はしすてむ、設定、あるいはバグが原因だがそのうちのどれが原因かはエラーメッセージからはわからないし、どの設定をミスしたのかもエラーメッセージからはわからない。当然 fetch failures はどのノードで設定ミスしたのかも教えてくれない。
m.r.s.c.m 0.05 by defaultt.h.t 40 by default
d.d.m.x 256 by default
one large cluster doesn't necessarily show all the different dependencies;cloudera has seen a lot of diverse operation clusters.part of what cloudera does is provide tools to help diagnose and understand how hadoop operates巨大なクラスタは、必ずしも全ての異なる依存関係を表示するとは限らない。Clouderaでは多くの異なる運用をしているクラスタを見てきた。Cloudera がやってきたことの一つとして、hadoopを診断し、どうやってhadoopを運用するかを支援するソフトを開発した。
Not biased or anything but you can get it right the first time with Cloudera Mgr
