lustre bonnie++测试

发布于 2022-09-24 02:36:31 字数 5027 浏览 27 评论 0

用lustre做了个集群, 简单用bonnie++测试了一下, 贴个结果,大家评判一下。有许多对lustre不懂的地方, 还需要和大家多多交流.

用了三台linux机器做oss, 第台机器3个500G sata盘做ost,共9个ost,mdt和mgs在同一台机器上,64位rhel4.4系统, 使用的是TCP链接, 千M网卡,下面是在client上做的bonnie++测试结果。

  1. Version 1.03c       ------Sequential Output------ --Sequential Input- --Random-
  2.                     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
  3. Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
  4. CFSHOST  1G 11141  17 12233   2 11490   4 69465  99 787158  99  9484  19
  5.                     ------Sequential Create------ --------Random Create--------
  6.                     -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
  7.               files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
  8.                  16  1106   5  1013   9  1926   4  1115   5   980   8  1947   5
  9. 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
  10. Version 1.03c       ------Sequential Output------ --Sequential Input- --Random-
  11.                     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
  12. Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
  13. CFSHOST  2G 11644  18 11835   2 11422   3 69463  99 768134  99 +++++ +++
  14.                     ------Sequential Create------ --------Random Create--------
  15.                     -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
  16.               files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
  17.                  16  1128   6   992   8  1928   7  1118   5   991   8  2005   6
  18. 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
  19. Version 1.03c       ------Sequential Output------ --Sequential Input- --Random-
  20.                     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
  21. Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
  22. CFSHOST  4G 11655  18 11545   2 11441   3 69361  99 765375  99 +++++ +++
  23.                     ------Sequential Create------ --------Random Create--------
  24.                     -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
  25.               files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
  26.                  16  1129   5   972   9  1893   6  1118   5  1007   9  1937   5
  27. 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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(7

东京女 2022-10-01 02:36:31

性能正常,你可以在网卡驱动和Qos上做调整,测试的手段在多一些,bonnie++给你一个baseline性能,未必就是实际使用的性能.

我看到你1/2/4G的测试,从结果来看也没有什么好说的,应该是这样的表现的。

既然试验环境也有了,你就要做一些有意义的测试,比如 逐级减少文件尺寸,或者增加测试行为的多样性. 看看多线程的测试结果如何? (tiobench)

有条件的话,还可以在测试中考察lustre在不同通讯通路上的性能,比如吧GigE改成IB.

旧时光的容颜 2022-10-01 02:36:31

我还是不会用那个插件画图。呵呵

留蓝 2022-10-01 02:36:31

前几天在上面跑了一下应用, client上跑了缓存(文件大小平均在20M左右的样子), client的网口跑到500Mbits/s的时候(包括对外的流量和读写集群的流量), 爬下了, 集群系统好好。的。

谢谢nntp老大, 这几天在弄一个这样的项目,有什么问题还请多多指教啊。

有没有好的监控方案?LLNL?打算搭一个。

另外, 还有个问题想请教,如果OST没有容错, 如果有一个坏掉了, 比如一个磁盘, 把它拿下来了, 那以后访问放在那个ost上的数据(比如文件file1)的时候, MDT上应该还有那个文件file1的信息。 如果访问file1的时候, 是直接返回错误呢, 还是MDS会发现那个文件在所有OST上不存在(尽管MDT中有那个文件的元数据), 而把元数据清掉而返回文件不存在?如果是前者, 当OST坏掉了, 如果清掉MDS中的那些不完整的数据呢?

分分钟 2022-10-01 02:36:31

原帖由 moxnet 于 2008-2-26 20:32 发表
前几天在上面跑了一下应用, client上跑了缓存(文件大小平均在20M左右的样子), client的网口跑到500Mbits/s的时候(包括对外的流量和读写集群的流量), 爬下了, 集群系统好好。的。

谢谢nntp老大, 这几 ...

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 编辑 ]

痴情 2022-10-01 02:36:31

谢谢老大,我用1.6做过日处理60T的lustre,后来由于备份和容灾跟不上,只好撤了下来。 挺懊恼的

美羊羊 2022-10-01 02:36:31

原帖由 molecar 于 2008-2-28 00:47 发表
谢谢老大,我用1.6做过日处理60T的lustre,后来由于备份和容灾跟不上,只好撤了下来。 挺懊恼的

60T在国内算是相当大的项目了,应该上SFS.

无人问我粥可暖 2022-10-01 02:36:31

目前用了部分nas和san,lustre全部撤掉了!不过我还工作了。对lustre接触的就比较少了!

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文