moosefs快速结论
Siege是一个压力测试和评测工具，设计用于WEB开发这评估应用在压力下的承受能力：可以根据配置对一个WEB站点进行多用户的并发访问，记录每个用户所有请求过程的相应时间，并在一定数量的并发访问下重复进行。
下载：
wget ftp://sid.joedog.org/pub/siege/siege-latest.tar.gz
安装：
%./configure ; make
#make install
siege包含了一组压力测试工具：
SIEGE (1) Siege是一个HTTP压力测试和评测工具.
使用样例：
任务列表：www.murray.cn.url文件
http://www.murray.cn/tech/
http://www..murray.cn/tech/acdsee.html
….
siege -c 20 -r 2 -f www.murray.cn.url
参数说明：
-c 20 并发20个用户
-r 2 重复循环2次
-f www.murray.cn.url 任务列表：URL列表
=============================================================
1.1. 测试过程
测试1 Java_Write_15w_100K
MogileFS和MooseFS启动15个进程进行写数据，对比执行所需时间；
测试2 Siege_Read_c100_60mins_1storage
在192.168.80.15上使用Siege模拟100个并发用户通过http访问前端Nginx，持续60分钟随机访问50万个文件，这50万个文件均只存储在同一个Storage（Chunk）节点下；
测试3 Siege_Read_c200_60mins_1storage
在192.168.80.15上使用Siege模拟200个并发用户通过http访问前端Nginx，持续60分钟随机访问50万个文件，这50万个文件均只存储在同一个Storage（Chunk）节点下；
测试4 Siege_Read_c300_60mins_1storage
在192.168.80.15上使用Siege模拟300个并发用户通过http访问前端Nginx，持续60分钟随机访问50万个文件，这50万个文件均只存储在同一个Storage（Chunk）节点下；
=============================================================
结果分析
写操作测试：
同样Replication份数的情况下，MooseFS比MogileFS要慢较多。
读操作测试：
1， 当读的并发加大时，请求的成功率mooseFS比mogileFS要低，当超过200个并发，mooseFS的成功率降到较低水平；
2， mooseFS的反应时间比mogileFS要慢很多，从而处理请求的效率比mogileFS要低很多；
3， mooseFS所能达到的磁盘tps以及磁盘读速度比mogileFS要低，且从结果上看似乎存在瓶颈；
测试小结：
1，MooseFS从使用的逻辑上和NFS比较类似，使用MooseFS的时候都需要先在使用的客户端手动mount挂载点，然后再如使用本地磁盘一样使用其网络存储空间。
2，根据测试结果对比看出，MooseFS比MogileFS的读写性能、I/O表现差很多。
3，在测试过程中发现每次网络断开后，哪怕网络恢复了，都需要先手动umount一次，然后再重新mount回来才可以继续使用，如果网络出现经常中断不稳定的情况的话，就需要每次都umount，然后mount，如下：
umount /mnt/mfs
/usr/local/mfs/bin/mfsmount /mnt/mfs/ -H 192.168.80.9
还有，如果umount前有进程在对磁盘进行读写操作，则需要先手动把相关的程序找出来并杀死，否则umount的时候会提示“device is busy”。
4，当手工改变Replication份数后，会马上自动进行复制，但复制的速度极其缓慢。
写操作（Replication份数均为3），通过15个并发写15万数据只需要140分钟
下载：
wget ftp://sid.joedog.org/pub/siege/siege-latest.tar.gz
安装：
%./configure ; make
#make install
siege包含了一组压力测试工具：
SIEGE (1) Siege是一个HTTP压力测试和评测工具.
使用样例：
任务列表：www.murray.cn.url文件
http://www.murray.cn/tech/
http://www..murray.cn/tech/acdsee.html
….
siege -c 20 -r 2 -f www.murray.cn.url
参数说明：
-c 20 并发20个用户
-r 2 重复循环2次
-f www.murray.cn.url 任务列表：URL列表
=============================================================
1.1. 测试过程
测试1 Java_Write_15w_100K
MogileFS和MooseFS启动15个进程进行写数据，对比执行所需时间；
测试2 Siege_Read_c100_60mins_1storage
在192.168.80.15上使用Siege模拟100个并发用户通过http访问前端Nginx，持续60分钟随机访问50万个文件，这50万个文件均只存储在同一个Storage（Chunk）节点下；
测试3 Siege_Read_c200_60mins_1storage
在192.168.80.15上使用Siege模拟200个并发用户通过http访问前端Nginx，持续60分钟随机访问50万个文件，这50万个文件均只存储在同一个Storage（Chunk）节点下；
测试4 Siege_Read_c300_60mins_1storage
在192.168.80.15上使用Siege模拟300个并发用户通过http访问前端Nginx，持续60分钟随机访问50万个文件，这50万个文件均只存储在同一个Storage（Chunk）节点下；
=============================================================
结果分析
写操作测试：
同样Replication份数的情况下，MooseFS比MogileFS要慢较多。
读操作测试：
1， 当读的并发加大时，请求的成功率mooseFS比mogileFS要低，当超过200个并发，mooseFS的成功率降到较低水平；
2， mooseFS的反应时间比mogileFS要慢很多，从而处理请求的效率比mogileFS要低很多；
3， mooseFS所能达到的磁盘tps以及磁盘读速度比mogileFS要低，且从结果上看似乎存在瓶颈；
测试小结：
1，MooseFS从使用的逻辑上和NFS比较类似，使用MooseFS的时候都需要先在使用的客户端手动mount挂载点，然后再如使用本地磁盘一样使用其网络存储空间。
2，根据测试结果对比看出，MooseFS比MogileFS的读写性能、I/O表现差很多。
3，在测试过程中发现每次网络断开后，哪怕网络恢复了，都需要先手动umount一次，然后再重新mount回来才可以继续使用，如果网络出现经常中断不稳定的情况的话，就需要每次都umount，然后mount，如下：
umount /mnt/mfs
/usr/local/mfs/bin/mfsmount /mnt/mfs/ -H 192.168.80.9
还有，如果umount前有进程在对磁盘进行读写操作，则需要先手动把相关的程序找出来并杀死，否则umount的时候会提示“device is busy”。
4，当手工改变Replication份数后，会马上自动进行复制，但复制的速度极其缓慢。
写操作（Replication份数均为3），通过15个并发写15万数据只需要140分钟
若MooseFS设置的Replication份数为1，通过15个并发写15万数据只需要48分钟
======================================
最近有一套moosefs要上线，于是也在加急测试一下高可用的方案，如drbd+heartbeat 和 drbd+keepalive，实现起来真的不是那么容易。线下测试各种故障。请教一下大家生产环境下的如何做。
| moosefs服务是个高危服务，不能强杀，如果资源脚本控制没能正常的停止，后续如果网络恢复后切换回来后面启动的mfsmaster进程会与之前进程冲突，导致服务失败。这个问题是致命的，直接就导致drbd没有意义。moosefs做ha的代价大家懂的，耗钱，耗时，耗神。 没做HA最好，断电什么都白搭了。失望。。。 |