CDH4 Hive 0.8.1 でCLOSE_WAITが溜まる問題

CDH4もだいぶ安定稼働して死火山だわ~
って思ってたら、地味にマグマを蓄えていました。

解決してませんけど、斬新なCDH4ユーザのために記録しておきます。



Hive 0.8.1~ の問題点

Issuesに1ヶ月前に上がっていますが
  • HIVE-3335 / Thousand of CLOSE_WAIT socket when we using SymbolicInputFormat

  • Hiveを実行した時に、netstatで見たらCLOSE_WAITが溜まっている、という問題です。
    この人はCDH3u4だけど Hive 0.8.1 と 0.9 で試して両方ダメだったと報告しています。

    CDHのHiveバージョンはCDH3で0.7.1、CDH4で0.8.1 だから、普通はCDH4ユーザが対象となります。

    私はたまたまSLAVEでnetstatを見たら、25,000行あるのを発見して調べ始めました。
    放っておいたら普通に Too many open files とかになると思います。

    原因の特定は既にされていて、SymbolicInputFormat.java の66行目で open された接続が close していないから、のようです。

    検証した内容

    NodeManagerをrestartしたら、いったんCLOSE_WAITはゼロになるので、その状態からHiveを実行してみました。

    どうやら SHOW TABLES や CREATE TABLE ではCLOSE_WAITは残らない様子。
    SELECT * FROM tablename も残らない。
    どうやら MapReduce が走るクエリの場合に残るようです。例えば、SELECT COUNT(*) とか INSERT OVERWRITE TABLE tablename SELECT * FROM tablename WHERE ~ GROUP BY ~ とか。

    で、CLOSE_WAITが残るのはHiveClientサーバではなくて、ジョブが実行されるNodeManagerサーバのようで、こんな感じ。50010番はDataNodeですね。

    1回のジョブ当りに

  • NodeManagerとローカルのDataNodeへの接続
  • NodeManagerとHiveクライアント(または他NM)のDataNodeへの接続
  • が1~2行ずつ、1~2個のNodeManagerで残るようですが、詳しくは追っていません。今回の検証では、Map数が200のジョブとかも走らせてみましたが、だからCLOSE_WAITが多くなる、というわけではなかったです。



    CDH4にしてからNodeManagerがログも無しにスッと落ちたりするのはこの辺かな~と思ったりもしましたが、これ系は Too many open files になるはずなので・・・まだ安定とはいえないな~と。Hive 0.8.1 での他のバグにも少し困ってるので、0.9 にしてしまえと意気込んでもまだ直っていないという・・シクシク。

    ちょっと前に、同一のディレクトリエンドコンポーネントを使用したdfs.name.dirに起因するHDFSメタデータの破損の危険性 – Cloudera が出て、CDH4最強説を唱えたいところでしたが、今のところは CDH3u5 が勝ち組なのかな・・・と少し弱気になってみたり。