Hadoop SecondaryNameNodeのメモリ不足エラー

少々可愛がり方が足りなかったのか、SecondaryNameNodeでメモリ不足が発生して、機能が停止してしまいました。

その際の調査や修復の記録になります。



SecondaryNameNodeのおさらい

SNNの機能を復習するとこんな感じ。

  • SNNが定期的にNameNodeからfsimageとeditsログを取得する
  • SNNでfsimageにeditsを適用する
  • NameNodeにfsimageを送り返す
  • NameNodeとSNNにデフォで2世代分のfsimageが残る
  • NameNodeのedits_inprogressがeditsにローテートされて新しいedits_inprogressが始まる


  • 障害内容

    現象

  • SNN起動時は正常にfsimageを送り返してるように見える
  • period秒後の2回目以降はNameNodeに接続しようとすらしない
  • SNN管理画面 http://localhost:50090/ がレスポンスを返さなくなる。タイムアウトしない
  • 最新のfsimageがどこにもない危険な状態になる
  • NameNodeのedits_inprogressが肥大化する

  • エラーログ

    NameNodeの .log にもSNNの .log にも記録されず、SNNの .out にのみ記録されていました。内容は

    容量

    fsimageが 約550MB
    SNNプロセスの最大ヒープサイズがデフォの -Xmx1000m


    修復方法

    /etc/hadoop/conf/hadoop-env.sh でSNNオプションのみ環境変数を設定していなかったので、書いてSNNを再起動しました。

    SNN再起動後は、全て正常に動作し、定期チェックも行われました。


    反省

    今回の反省点は2つ。
  • ヒープサイズいじってない
  • 監視してない

  • ヒープサイズの方はSNNを信用していたというか、甘く見ていたというか。
    fsimageの容量に対して倍近いメモリでエラーになるとすると、将来的に結構・・・どうなんでしょう。
    SNNはいくらでも再起動できるから、監視さえちゃんとしていれば大事にはならないかもですが。

    監視の方はひと通りやってたつもりでしたが、SNNだけ抜けてました・・・
    わりと危ない状態が続いていたので、久々の冷や汗モンでしたね。
    なんとCDH4.1へのアップグレード作業中に気づきました。。


    大事な注意点

    SNNのマージ処理が完了すると、このようなログが .log に記録されます。障害発生時はこれが記録されていませんでした。
    WARN以上にしているとこれだけ延々と記録されます。

    なので、SNNの監視としてはこのどちらかでよさそうです。

  • このログが定期的に記録されているか
  • HTTP管理画面の Last Checkpoint Time が period 以内になっているか(※接続タイムアウトを仕込むこと)


  • 今後

    とりあえずSNNはこれで良しとしますが、SNN自体がもうアレなので、
    CheckpointNodeやBackupNodeが今どうなってるか調べたいところ。
    どうやら設定項目はあるようですが、まだ何も試していません。

    あとは Quorum Journal Design も仕組みは読んだけど試してないのでやらなくては。

    Impalaもあるし、CDHだけでもお腹いっぱいでエンジニア冥利に尽きますね。