I/O 和FS测试结果

nntp

刚才在 服务器架设回答了一个网友的关于软RAID0的性能问题。突然记起来我做过详细的测试.  这里给出连接，供大家参考.

http://www.linuxtea.org/~joe/iotest/

因为一个工作上的原因，我需要一组比对数据和真实的服务器环境作比对，一共做了13组测试

1. software RAID bonnie++ testing result

2. LVM Striping bonnie++ testing result

3. software RAID tiobench testing result

4. LVM Striping tiobench testing result

5. Single Disk ST380013AS bonnie++ testing result

6. Single Disk ST380817AS bonnie++ testing result

7. Single Disk ST380013AS tiobench testing result

8. Single Disk ST380817AS tiobench testing result

9. Two big partition with raid0 and ext2 bonnie++ testing result

10. Two big partition with raid0 and jfs bonnie++ testing result

11. Two big partition with raid0 and reiserfs bonnie++ testing result

12. Two big partition with raid0 and xfs bonnie++ testing result

13. Eight partitions with raid0 bonnie++ testing result

很多朋友做测试的时候都用iozone, iometer之类得乱用一气，这些东西测试的目标和范围都是差别很大的.得到的结果对于测试者的意义也达不相同.

我这13组测试，测试的结果并不是某个FS或者某个I/O方式的性能，而是在某种组合下，我的Application在上面能够得到的overall性能. 具体测出来某个FS或I/O方式的性能对实际使用的人没有很大意义.

happy day.

kenduest

很好的文章，感謝您的分享。

==

yangze_tj

如果要是图形或线形说明，再加上针对这个个案的分析说明就好了

nntp

原帖由 yangze_tj 于 2006-2-20 13:02 发表
如果要是图形或线形说明，再加上针对这个个案的分析说明就好了

数据都在那里，你可以做一下.

cugag

看了老大的测试很佩服，也想自己做一做，有几个问题不明白，请版老大指点：
1、上述测试中用到的文件系统是在同一个操作系统下实现的吗？（好像不太公平，各发行版应该有针对自己文件系统的优化）
2、Two big partition 理解为两个大的分区合适吗？

leaper

我这打不开

谁有下载的共享一下

baif

the domain name www.linuxtea.org could not be resolved.

baif

nntp我很有兴趣看看你的测试结果。能不能想个办法？

巧花

在bonnie++的测试中看到的测试结果中出现很多++++++我知道这是由于测试时间低于500MS时造成的 特别在读写测试小文件的性能方面出现+++++的时候就非常多,现在公司需要测试一些小于读写100M的文件的性能(需用有应用程序和没有应用程序的时候的读写性能做对比)可是当没有运行应用程序时 很多结果都出现++++,导致无法去对比结果(系统的RAM有2048M)我试过用-r去指定RAM的大小 但是仍然出现这种情况!想具体问问当bonnie++的数值结果为多少时会出现++++(主要需要RANDOM seek)数据或者有什么方法尽量不出现+++!!也希望能够介绍一些测试系统读写小文件性能比较好的工具(感觉bonnie++测试读写速率的方面比DT,iozone的范围要广些 但是对于小文件就一直不是很准确)  谢谢

嘿嘿 其中一个小问题 感觉你应该比较熟悉这些软件就问问了 新手 问得满不专业的 还请见谅

[ 本帖最后由 巧花 于 2006-12-31 10:51 编辑 ]

nntp

小文件不用测， 目前在非研究领域(即生产应用领域)，还没有一种软件技术，可以解决海量小文件的读写性能问题.

无论你使用clustered filesystem还是parallel filesystem, 性能都很糟糕.  striping得越大，性能越差，那些连metadata 的管理都分布出去的就更加完蛋了.

从施工的切实可操作性以及性价比上，还是用集中存储+高性能存储硬件的方案在目前还没有一个更好的方法之前的临时方法.