最近发现hadoop集群上数据清洗业务运行的越来越慢,从开始的3-4分钟到现在的10-30分钟,性能出现了几倍的下滑,在网上和hadoop日志中折腾了半天后,发现清洗业务运行的map作业和文件块分布在不同的服务器上,且这种现象还比较多,这就是说,map程序必须从其他的服务器上拷贝数据块,这会导致map程序性能下滑。
在这过程中,还按照网上的建议优化了hadoop集群jvm的运行参数:
-XX:+UseConcMarkSweepGC
分别在 HADOOP_OPTS和mapred.child.java.opts进行了设置,但是没有办法判断是否能提高集群的性能?
此外,hadoop集群以使用的heap size一直在增加,不知道是不是正常现象?
2)hadoop lzo压缩库问题
mapred程序报错:native lzo library not found
然而报错的服务器上面已经正常安装了lzo压缩库,配置也和其他的服务器一致,为什么就单独这台服务器报错呢?
修改配置文件,修改系统配置文件,折腾了半天还是没能消除报错,更为严重的在于不知道什么地方出了问题?
实在没辙了,就将有问题的tasktracker的启动命令和正常的启动命令对比,这下终于发现了问题所在:
报错:-Djava.library.path=/opt/modules/hadoop/hadoop-0.20.203.0/bin/../lib/native/Linux-i386-32 正常:-Djava.library.path=/opt/modules/hadoop/hadoop-0.20.203.0/bin/../lib/native/Linux-amd64-64原来报错的tasktracker使用的是32为本地库,而正常应该是使用64位本地库
错误原因是找到了,但是在仔细查看hadoop的配置文件后发现,配置文件中配置的就是64位本地库,没有配错,但是tasktracker还是报错???
3)hadoop lzo压缩库安装:
安装lzo压缩库时,可能遇上依赖库缺失的问题:
[root@test rnc]# rpm -ivh lzo-2.04-1.el5.rf.i386.rpm error: Failed dependencies: libc.so.6(GLIBC_2.4) is needed by lzo-2.04-1.el5.rf.i386 rtld(GNU_HASH) is needed by lzo-2.04-1.el5.rf.i386