HDFSFUSE访问频繁致使系统奔溃

集群规模几百台，每天有大量的MR任务在并行跑流程。主要业务做图片流数据解密计算生成高清图像。

随着集群使用的时间增长，发现集群越来越缓慢，甚至集群压力特别大的时候，导致操作系统莫名重启。

每天都会有6~8台无规律的操作系统压力过大重启。

排查时间和周期都非常的长，用了长达1个月的时间，各种检查，主要从两个方面着收：

• 我们提供的集群软件本身检查

• 客户开发的分布式应用程序检查

• 操作系统层面的资源监控和管理检查

集群自身的检查

主要针对资源管理入手，从集群资源的每个组件使用资源的分配和限制，利用cgroup隔离进程，针对集群YARN的资源管理调度的控制，基于标签的调度，基于cgroup隔离，资源队列控制，并发控制，最大限度的提高集群资源利用率，尽量使任务分配到更多的节点执行，增强集群安全管控。

然而，并没有解决问题。

客户开发应用程序检查

主要针对客户开发的c/c++程序代码优化数据处理流程，由于中间涉及到大量的私有算法和科学计算的算法，无法并行化，所以访问集群数据的方式是利用HDFS-FUSE的方式。

测试发现，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/