Successfully reported this slideshow.

More Related Content

Related Books

Free with a 14 day trial from Scribd

See all

Hadoop Troubleshooting 101 - Japanese Version

  1. 1. Hadoop Troubleshooting 101(日本語版) 嶋内 翔, Cloudera
  2. 2. Hadoop クラスタを壊す 7つの設定ミス
  3. 3. Agenda • チケット分析 • 設定ミスとは? • メモリの管理ミス • TT OOME • JT OOME • Native Threads • スレッドの管理ミス • Fetch Failures • Replicas • ディスクの管理ミス • No File • Too Many Files • Cloudera Manager
  4. 4. Agenda • チケット分析 • 設定ミスとは? • メモリの管理ミス • TT OOME • JT OOME • Native Threads • スレッドの管理ミス • Fetch Failures • Replicas • ディスクの管理ミス • No File • Too Many Files • Cloudera Manager
  5. 5. チケット分析 • 設定ミスそれ自体が原因のチケットは2%以下 – 一般的なソフトウェアではこうした単純なミスが大半を占める • 最初に報告される症状 ≠ 根本原因 • 設定が間違ってるかどうかはログを少し調べただけではわ からない
  6. 6. チケットをコンポーネント別に分類
  7. 7. Agenda • チケット分析 • 設定ミスとは? • メモリの管理ミス • TT OOME • JT OOME • Native Threads • スレッドの管理ミス • Fetch Failures • Replicas • ディスクの管理ミス • No File • Too Many Files • Cloudera Manager
  8. 8. 設定ミスとは? • Hadoop あるいは OS の設定ファイルの変更を必要とする あらゆるチケットのこと • 35% のチケットが該当 • リソース割り当て: メモリ, ファイルディスクリプタ, ディ スク領域
  9. 9. チケットを原因別に分類
  10. 10. なぜ設定ミスを気にする 必要があるのか?
  11. 11. リソースを過剰要求する MR/HBase クラスタの一生は 卑劣で、残酷で、短いものになる。 (トマス・ホッブズ先生すいません) 訳参考: http://cruel.org/econthought/profiles/hobbes.html
  12. 12. MR ヒープの過剰要求はswapを引き起こす。 swap により RegionServer はタイムアウトし、そして死ぬ。 RegionServer が死んだことで MR タスクが失敗し、 その結果 MR ジョブが死ぬ
  13. 13. 犯人は誰? HBase 死亡の原因は MR の設定ミスだった
  14. 14. オリジナルスライドの発表者 • Kate Ting o Customer Operations Engineer, Cloudera o 9 ヶ月で100以上のHadoopクラスタのトラブルシュー ティングに携わってきた o kate@cloudera.com • Ariel Rabkin o Customer Operations Tools Team, Cloudera(インター ン) o UC Berkeley CS PhD 候補生 o 設定バグの診断に関する論文 o asrabkin@eecs.berkeley.edu
  15. 15. 自己紹介 • Sho Shimauchi(嶋内 翔) o Cloudera カスタマーオペレーションズエンジニア o 主に日本のユーザを中心にサポートを提供している o sho@cloudera.com o twitter: @shiumachi
  16. 16. Agenda • チケット分析 • 設定ミスとは? • メモリの管理ミス • TT OOME • JT OOME • Native Threads • スレッドの管理ミス • Fetch Failures • Replicas • ディスクの管理ミス • No File • Too Many Files • Cloudera Manager
  17. 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. 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. 19. (Mappers + Reducers)* Child Task Heap + DN heap + Total RAM TT heap + 3GB + RS heap + Other Services' heap RS: Region Server
  20. 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. 21. 2. JobTracker Out of Memory Error • どういう意味? o JT のメモリ使用量の合計 > 割り当て RAM • 何が原因? o タスクが小さすぎ o job ヒストリが多すぎ
  22. 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. 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. 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. 25. Agenda • チケット分析 • 設定ミスとは? • メモリの管理ミス • TT OOME • JT OOME • Native Threads • スレッドの管理ミス • Fetch Failures • Replicas • ディスクの管理ミス • No File • Too Many Files • Cloudera Manager
  26. 26. 4. Too Many Fetch-Failures INFO org.apache.hadoop.mapred.JobInProgress: Too many fetch-failures for output of task:
  27. 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. 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. 29. 5. Not Able to Place Enough Replicas WARN org.apache.hadoop.hdfs.server.namenode.FSNamesystem: Not able to place enough replicas
  30. 30. 5. Not Able to Place Enough Replicas • どういう意味? o NN が一部の DN を選択できない
  31. 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. 32. 5. Not Able to Place Enough Replicas • どうすれば解決できる? o dfs.datanode.max.xcievers = 4096 として、DN を再起 動する o ダウンしてるノードやラックを探す o ディスク領域を確認する o log ディレクトリが容量を食っているか、暴走した タスクがディスクの空きを埋めてるかもしれない o リバランスしましょう
  33. 33. Agenda • チケット分析 • 設定ミスとは? • メモリの管理ミス • TT OOME • JT OOME • Native Threads • スレッドの管理ミス • Fetch Failures • Replicas • ディスクの管理ミス • No File • Too Many Files • Cloudera Manager
  34. 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)
  35. 35. ストレージ総計 DFS 領域 MR 領域
  36. 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. 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. 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. 39. Agenda • チケット分析 • 設定ミスとは? • メモリの管理ミス • TT OOME • JT OOME • Native Threads • スレッドの管理ミス • Fetch Failures • Replicas • ディスクの管理ミス • No File • Too Many Files • Cloudera Manager
  40. 40. さらに詳しい情報はこちら • Avoiding Common Hadoop Administration Issues: http://www.cloudera.com/blog/2010/08/avoiding-common-hadoop- administration-issues/ • Tips for Improving MapReduce Performance: http://www.cloudera.com/blog/2009/12/7-tips-for-improving- mapreduce-performance/ • Basic Hardware Recommendations: http://www.cloudera.com/blog/2010/03/clouderas-support-team- shares-some-basic-hardware-recommendations/ • Cloudera Knowledge Base: (注: Cloudera のお客様のみ閲覧可能) http://ccp.cloudera.com/display/KB/Knowledge+Base
  41. 41. 謝辞 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
  42. 42. 今日の教訓 • 設定はあなたの責任、バグはコミュニ ティの責任 • 設定ミスは診断を困難にします • 最初は Cloudera Manager を使って正し く理解しましょう

Editor's Notes

  • 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&apos;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もしクラスタが壊れていたら、まず設定ミスを疑ってください。でも自分で診断するのは難しいと思う。なぜならエラーメッセージは根本原因ときっちり結びついているわけじゃないから。
  • ディスクへの書き出しが多くなる-&gt; spill が多くなる
  • @tlipcon if sum(max heap size) &gt; 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&apos;t know which misconfig from err msg also ff doesn&apos;t show up on the node where it&apos;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&apos;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
  • ×