lustre bonnie++测试
用lustre做了个集群, 简单用bonnie++测试了一下, 贴个结果,大家评判一下。有许多对lustre不懂的地方, 还需要和大家多多交流.
用了三台linux机器做oss, 第台机器3个500G sata盘做ost,共9个ost,mdt和mgs在同一台机器上,64位rhel4.4系统, 使用的是TCP链接, 千M网卡,下面是在client上做的bonnie++测试结果。
- Version 1.03c ------Sequential Output------ --Sequential Input- --Random-
- -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
- CFSHOST 1G 11141 17 12233 2 11490 4 69465 99 787158 99 9484 19
- ------Sequential Create------ --------Random Create--------
- -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
- 16 1106 5 1013 9 1926 4 1115 5 980 8 1947 5
- CFSHOST,1G,11141,17,12233,2,11490,4,69465,99,787158,99,9483.6,19,16,1106,5,1013,9,1926,4,1115,5,980,8,1947,5
- Version 1.03c ------Sequential Output------ --Sequential Input- --Random-
- -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
- CFSHOST 2G 11644 18 11835 2 11422 3 69463 99 768134 99 +++++ +++
- ------Sequential Create------ --------Random Create--------
- -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
- 16 1128 6 992 8 1928 7 1118 5 991 8 2005 6
- CFSHOST,2G,11644,18,11835,2,11422,3,69463,99,768134,99,+++++,+++,16,1128,6,992,8,1928,7,1118,5,991,8,2005,6
- Version 1.03c ------Sequential Output------ --Sequential Input- --Random-
- -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
- CFSHOST 4G 11655 18 11545 2 11441 3 69361 99 765375 99 +++++ +++
- ------Sequential Create------ --------Random Create--------
- -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
- 16 1129 5 972 9 1893 6 1118 5 1007 9 1937 5
- CFSHOST,4G,11655,18,11545,2,11441,3,69361,99,765375,99,+++++,+++,16,1129,5,972,9,1893,6,1118,5,1007,9,1937,5h
复制代码
有点不明白: 为什么千M网卡, 能跑700多Mbytes/s的IO?
还有一个用 iozone测试结果画的立体图:
[ 本帖最后由 moxnet 于 2008-2-24 12:42 编辑 ]
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(7)
性能正常,你可以在网卡驱动和Qos上做调整,测试的手段在多一些,bonnie++给你一个baseline性能,未必就是实际使用的性能.
我看到你1/2/4G的测试,从结果来看也没有什么好说的,应该是这样的表现的。
既然试验环境也有了,你就要做一些有意义的测试,比如 逐级减少文件尺寸,或者增加测试行为的多样性. 看看多线程的测试结果如何? (tiobench)
有条件的话,还可以在测试中考察lustre在不同通讯通路上的性能,比如吧GigE改成IB.
我还是不会用那个插件画图。呵呵
前几天在上面跑了一下应用, client上跑了缓存(文件大小平均在20M左右的样子), client的网口跑到500Mbits/s的时候(包括对外的流量和读写集群的流量), 爬下了, 集群系统好好。的。
谢谢nntp老大, 这几天在弄一个这样的项目,有什么问题还请多多指教啊。
有没有好的监控方案?LLNL?打算搭一个。
另外, 还有个问题想请教,如果OST没有容错, 如果有一个坏掉了, 比如一个磁盘, 把它拿下来了, 那以后访问放在那个ost上的数据(比如文件file1)的时候, MDT上应该还有那个文件file1的信息。 如果访问file1的时候, 是直接返回错误呢, 还是MDS会发现那个文件在所有OST上不存在(尽管MDT中有那个文件的元数据), 而把元数据清掉而返回文件不存在?如果是前者, 当OST坏掉了, 如果清掉MDS中的那些不完整的数据呢?
client 趴下应该是client的问题.
lustre监控,用nagios即可.
一个OSS上面的某个OST,维护这一个本地stripe列表,每个OSS上的OST都有. 不想你想的那样是以某文件作为单位的. 横向看过去,所有的相关OST组成的是一个汇聚stripes的pool, MDS作为master copy保留有stripes lists.
当某个OST废掉之后,比如对应的盘阵硬件故障不可用. lustre保持着内部在各个节点上的一致性检查,当client访问到这个废掉的OST之后,如果之前没有经过检查间隔,就会报错,同时触发一个此OST对应的MDS上master copy的更新操作.更新完了之后,相应的stripe lists会按照检查间隔,同步到每个OSS的相关OST上.
我看到欧洲高能还有美国LLNL的人在作大型的lustre的时候, 除了购置强劲的Lustre交换网络比如Qudrics,还通过对lustre检查间隔以及OST failed之后大量OSS节点和MDS的stripe lists同步的缺省操作代码的修改,极大的优化了lustre的性能. 你可以用google搜到CERN和LLNL的人撰写的相关论文和实验室级的测试分析.
要做好lustre的性能优化,最最影响lustre性能的就是write/read的allocation优化,其次是device driver的优化,包括比如2.6kernel中的Zero Copy.
等等.你可以在网上找到大量的lustre优化的参考建议.
HP和Intel很早就介入CFS公司的lustre研发,我推荐你查阅HP的SFS, SFS是针对lustre进行充分优化的成型方案,适合用在生产环境. 由于lustre的部署对架构和实施经验要求非常高,所以build from scratch 对于普通的个人是很难做到及格的,成型的方案会让你的项目成功率高很多.
[ 本帖最后由 nntp 于 2008-2-27 04:10 编辑 ]
谢谢老大,我用1.6做过日处理60T的lustre,后来由于备份和容灾跟不上,只好撤了下来。 挺懊恼的
60T在国内算是相当大的项目了,应该上SFS.
目前用了部分nas和san,lustre全部撤掉了!不过我还工作了。对lustre接触的就比较少了!