hadoop运维记录1

最新推荐文章于 2024-11-01 15:17:16 发布

原创最新推荐文章于 2024-11-01 15:17:16 发布 · 2.9k 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#hadoop #dependencies #服务器 #集群 #library #作业

hadoop 专栏收录该内容

63 篇文章

订阅专栏

本文探讨了Hadoop集群上数据清洗业务性能下降的问题，详细分析了性能下滑的原因，包括数据块分布不均导致的网络延迟，以及在优化jvm运行参数后性能未见提升的情况。同时，解决了一个关于lzo压缩库安装失败的问题，最终通过确认并修正任务跟踪器使用的本地库位数来解决问题。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

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