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

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

Hive 0.8.1～ の問題点

Issuesに１ヶ月前に上がっていますが

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 が勝ち組なのかな・・・と少し弱気になってみたり。