MooseFS之虚拟机惹的祸

说在前面

我们平时在技术研究和支撑的过程中常常会遇到一些坑，我想把踩过的坑分享出来是一种美德，后续打算写一个系列，慢慢积累，希望能够帮到大家。

问题描述

这是最近遇到的一个MooseFS的坑，觉得有点意思，分享一下。

国庆假期前，我们的MooseFS集群刚好有一台ChunkServer机器挂了，国庆期间没人维护集群，因此只好在假期后维修机器，修好后重新启动，结果导致Master无响应几十分钟，整个集群瘫痪了，情况非常恶劣。运维同学查看Master的日志/var/log/messages，发现总共有几十万行： chunkserver has nonexistent chunk (00000000139811BC_00000001), so create it for future deletion 这样的日志。在Master无响应的几十分钟里，其实有尝试重启Master和ChunkServer，但都没用，最后等“nonexistent chunk”汇报完了之后才恢复正常。

问题分析

有日志其实好办，直接找到该日志对应的源码，查看了相关的处理逻辑，其处理流程大概是这样的：

1. ChunkServer启动之后会向Master汇报Chunk信息。
2. Master收到Chunk信息之后会逐个检查Chunk_id是否存在。
3. 如果不存在，表示该chunk_id其实已经删除了（chunk_id过期），于是写syslog日志，然后调用chunk_new()创建该chunk，并设置lockedto属性为7天后。

看了几遍这个处理逻辑，基本都是内存操作，并且Master是单线程的进程，并不存在全局锁，应该不会导致Master阻塞无响应。由于我们使用的版本是1.6.19，于是想到需要对比一下最新的1.6.27源码，发现在1.6.27中已经把写syslog日志的这句代码注释掉了。整个过程只有这个地方是写磁盘的，所以它的嫌疑最大。

于是我们做了如下测试：

• 生成1个1万行的文本文件test_syslog.txt。
• 利用logger命令写入/var/log/messages测试syslog写入速度

首先在一台物理机上进行测试：

time logger -f test_syslog.txt 

real0m0.141s
user0m0.063s
sys 0m0.031s

从测试结果看，syslog写磁盘其实是很快的，TPS能够达到7万以上，按理不会导致Master长时间无响应，除非硬盘有问题。于是让运维同学按照在线上的Master做同样的测试，结果如下：

time logger -f test_syslog.txt 

real0m9.281s
user0m0.222s
sys 0m0.217s

线上TPS只能达到1千，与测试机的性能相差65倍左右。 原来，在不久前运维同学因为机器资源紧张把Master从物理机换成了虚拟机，而虚拟机的镜像存储是直接挂在iSCSI设备上的，结果写syslog变成了直接写网络iSCSI设备而不是本地磁盘，因此性能大大下降。

解决方法

1. 修改Master的代码，直接注释掉该syslog打印语句，可缓解这个情况。
2. Master迁移回物理机，可预防更多的问题发生。

慎用虚拟机

总结一下，MooseFS的Master是单线程的程序，并不能发挥多核CPU的优势，由于大部分的处理逻辑都是内存操作，因此并不会存在太大的问题，但一旦涉及到磁盘I/O就有可能导致阻塞，严重的话整个集群会瘫痪掉，因此不建议把Master放在虚拟机中。

单线程是个硬伤

其实MooseFS的代码写的还是不错的，但Master的单线程机制不能够发挥多核CPU的优势，导致其性能有很大的瓶颈，因此大家在做存储选型的时候要注意了。我们在相同集群上测试过MooseFS和HDFS小文件的读写性能，其中MooseFS的写TPS只能达到100，读TPS只能达到1000，而HDFS的写TPS能达到1000以上，读TPS能达到10000以上，两者相差10倍。

可想而知，MooseFS单线程是一个硬伤，并不适合高并发的业务。