hadoop运维记录1

       最近发现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.rpmerror: 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