少々可愛がり方が足りなかったのか、SecondaryNameNodeでメモリ不足が発生して、機能が停止してしまいました。
その際の調査や修復の記録になります。
SecondaryNameNodeのおさらい
SNNの機能を復習するとこんな感じ。障害内容
現象
エラーログ
NameNodeの .log にもSNNの .log にも記録されず、SNNの .out にのみ記録されていました。内容は|
1 |
Checkpoint Edits Dirs: [file://${hadoop.tmp.dir}/dfs/namesecondary]" java.lang.OutOfMemoryError: Java heap space |
容量
fsimageが 約550MBSNNプロセスの最大ヒープサイズがデフォの -Xmx1000m
修復方法
/etc/hadoop/conf/hadoop-env.sh でSNNオプションのみ環境変数を設定していなかったので、書いてSNNを再起動しました。|
1 2 3 4 5 6 7 8 |
# 元々ノードごとに設定するためコメントアウトしてある #export HADOOP_HEAPSIZE=2000 # 今回追加したところ export HADOOP_SECONDARYNAMENODE_OPTS="-Xmx2g" # 元々書いてあったところ export HADOOP_SECONDARYNAMENODE_OPTS="-Dcom.sun.management.jmxremote $HADOOP_SECONDARYNAMENODE_OPTS" |
SNN再起動後は、全て正常に動作し、定期チェックも行われました。
反省
今回の反省点は２つ。ヒープサイズの方はSNNを信用していたというか、甘く見ていたというか。
fsimageの容量に対して倍近いメモリでエラーになるとすると、将来的に結構・・・どうなんでしょう。
SNNはいくらでも再起動できるから、監視さえちゃんとしていれば大事にはならないかもですが。
監視の方はひと通りやってたつもりでしたが、SNNだけ抜けてました・・・
わりと危ない状態が続いていたので、久々の冷や汗モンでしたね。
なんとCDH4.1へのアップグレード作業中に気づきました。。
大事な注意点
SNNのマージ処理が完了すると、このようなログが .log に記録されます。障害発生時はこれが記録されていませんでした。WARN以上にしているとこれだけ延々と記録されます。
|
1 |
WARN org.apache.hadoop.hdfs.server.namenode.SecondaryNameNode: Checkpoint done. New Image Size: 572651837 |
なので、SNNの監視としてはこのどちらかでよさそうです。
今後
とりあえずSNNはこれで良しとしますが、SNN自体がもうアレなので、CheckpointNodeやBackupNodeが今どうなってるか調べたいところ。
どうやら設定項目はあるようですが、まだ何も試していません。
あとは Quorum Journal Design も仕組みは読んだけど試してないのでやらなくては。
Impalaもあるし、CDHだけでもお腹いっぱいでエンジニア冥利に尽きますね。
Hadoop SecondaryNameNodeのメモリ不足エラー への3件のコメント