集群规模几百台,每天有大量的MR任务在并行跑流程。主要业务做图片流数据解密计算生成高清图像。
随着集群使用的时间增长,发现集群越来越缓慢,甚至集群压力特别大的时候,导致操作系统莫名重启。
每天都会有6~8台无规律的操作系统压力过大重启。
排查时间和周期都非常的长,用了长达1个月的时间,各种检查,主要从两个方面着收:
我们提供的集群软件本身检查
客户开发的分布式应用程序检查
操作系统层面的资源监控和管理检查
集群自身的检查
主要针对资源管理入手,从集群资源的每个组件使用资源的分配和限制,利用cgroup隔离进程,针对集群YARN的资源管理调度的控制,基于标签的调度,基于cgroup隔离,资源队列控制,并发控制,最大限度的提高集群资源利用率,尽量使任务分配到更多的节点执行,增强集群安全管控。
然而,并没有解决问题。
客户开发应用程序检查
主要针对客户开发的c/c++程序代码优化数据处理流程,由于中间涉及到大量的私有算法和科学计算的算法,无法并行化,所以访问集群数据的方式是利用HDFS-FUSE的方式。
使用方式 | 数据大小 | 时间 |
---|
HDFS-PUT | 9.8G | 32.639s |
HDFS-PUSE | 9.8G | 1m17.294s |
NFSGateway | 9.8G | 1m58.294s |
测试发现,Hadoop提供的几种把HDFS变成挂载到某个服务器,提供本地化命令操作的方式,FUSE性能是最高的。
经过优化流程,客户开发的应用程序只从FUSE取数据,大量写数据的操作利用c++在本地先写成功,在移动到FUSE的目录中,减少很多不必要的小文件写入,通过合并文件,优化整体程序的处理效率。
然而,并没有解决问题。
操作系统层面的资源监控和管理检查
每次几个大的流程启动之后,操作系统CPU直接飘红,通过集群监控系统直接失去心跳。
未来解决问题,我们从以下几个方面入手:
集群监控工具
Ambari grafana 监控每一台服务器的集群CPU、内存、网络、磁盘IO等资源
Ganglia 检测全局主机CPU、网络、内存、磁盘等资源变化
Ambari Metrics 检测集群Hadoop生态用到的组件指标,JVM参数等
发现有局部集群会出现持续数分钟CPU洪峰,能挺过去的,一会心跳都恢复正常,而压力过大的直接操作系统重启。
Debug工具
CGROUP CPU 资源隔离,限制FUSE进程,有明显改善,至少操作系统不崩溃了。
GDB 调试 C 程序,跟踪Java调用Fuse C的library库情况,没有发现进一步信息。
Jstack 分析线程状态,定位到cpu占用率较高的线程,分析定位问题。
cpulimit限制CPU利用率,缓解系统压力。
经过资源隔离控制,明显改善,但是机器压力过大还是会失去联系,压力过后就会恢复,并未根本解决问题。
通过监控某些流程,发现流程启动之后,有大量的文件访问,导致CPU洪峰,进一步追踪目录。
发现竟然在某个目录下写了25万多个小文件,而且是存储在HDFS上的大量小文件。
这是一个临时目录,数据量不是很大,经过统计数据量很小,但是文件个数多,ls
一下就导致机器卡死。
进一步跟踪发现,大量数据访问分布式文件系统FUSE挂载的数据,单个集群的inode有限,一个目录下有大量的小文件,大量的IO访问,直接导致系统被拖死,是Linux操作系统的限制。
总结
使用方式问题。分布式文件系统挂载到某个机器,一台普通的x86服务器容纳几十PB的数据挂载到某个目录,一台服务器根本无法承受这样的数据量。
文件系统使用不合理。几十万文件放到一个目录下本身就是Linux系统的大忌,没有任何目录划分,list就可能导致系统被拖死,没用任何清理临时数据的程序逻辑,属于开发人员犯的常规错误。
程序层面的优化。通过改造可以分布式化的程序,利用分布式这样的技术提升整体数据处理效率。
业务流程优化。通过有效的数据处理流程优化,虽然没有解决根本问题,但提升了整体处理效率。
资源管理和安全。通过多集群整体的资源分配、安全管控提高了集群的运营和整体资源利用率。
统一资源管理。很多程序都是单机运行,没有利用YARN进行统一调度和资源分配,导致集群资源利用率不均衡,一些机器压力很大,一些机器长时间空闲,可以利用Docker,CGroup技术融合到YARN中进行资源隔离,统一集群资源管理,提升集群资源利用率,更快的完成计算任务。
分布式系统复杂。分布式系统,应用程序很难追踪和重现,分布式在多台机器,调试复杂和耗时,一般技术人员很难掌握,无法用好这样的技术,需要企业级的分布式软件产品来保障,全新的集群开发和使用规范指导他们开发出健壮的分布式程序。
欢迎关注微信公众号,第一时间,阅读更多有关云计算、大数据文章。
原创文章,转载请注明: 转载自Itweet的博客
本博客的文章集合:
http://www.itweet.cn/blog/archive/