POPPUR爱换

标题: 烦躁，网上说的没一个准的，烦了，设置成8k [打印本页]

作者: 含笑半步癫 时间: 2009-6-3 23:32
提示: 作者被禁止或删除内容自动屏蔽

作者: res 时间: 2009-6-3 23:54

我也搞不懂了，都说设置成卡支持的最大条带好。我的3个maw，设置128kb持续居然只有80，和单快盘一样，设置成64持续有193

作者: shuhua_114 时间: 2009-6-4 00:37
噢噢噢？！！！

作者: hzyw 时间: 2009-6-4 00:49
进来学习下

作者: max1975cn 时间: 2009-6-4 01:21
我也不太懂直接设置成4K 用了好几年了还没从做过系统

作者: harleylg 时间: 2009-6-4 03:10
不会有不良后果……
理论上来说，条带越小的话，CPU占用率越低，持续速率越小，随机速率越快……
不过很多时候跟盘/卡都有关系。所以最好还是自己各种设置测一下。普通应用做系统盘的话，建议用PC Mark来测，看硬盘分数，尤其是Windows启动/应用程序载入/游戏载入三项的成绩。

作者: bcyj 时间: 2009-6-4 03:23

不会有不良后果……
理论上来说，条带越小的话，CPU占用率越低，持续速率越小，随机速率越快……
不过很多时候跟盘/卡都有关系。所以最好还是自己各种设置测一下。普通应用做系统盘的话，建议用PC Mark来测，看硬盘 ...
harleylg 发表于 2009-6-4 03:10

你说的完全相反了。。
没缓存、缓存小、没开预读的卡在大条带下持续低主要是这样一个情况，例如条带大小为64K,我现在要按64k对齐的每次读取64k,那就变成了先读一个盘，再读另一个盘，没有发生同时读取了。
但是有缓存的预读可以消除这种情况
在目前的卡来说最优性能基本可以按这样来算（去尾，如得70K就取64K）：
条带大小＝缓存/1024/盘数，如 512M/1024/2 = 256k

作者: bcyj 时间: 2009-6-4 03:29
上面说的是r0的，如果是r5 r6，就要看卡的运算能力和条带长度来做个平衡，缓存大小倒不是重点了

作者: harleylg 时间: 2009-6-4 05:50

你说的完全相反了。。
没缓存、缓存小、没开预读的卡在大条带下持续低主要是这样一个情况，例如条带大小为64K,我现在要按64k对齐的每次读取64k,那就变成了先读一个盘，再读另一个盘，没有发生同时读取了。
但是有 ...
bcyj 发表于 2009/6/4 03:23

我是说反了，正确应该是“条带越小的话，CPU占用率越高，持续速率越小，随机速率越快”，严格点来说不应该说随机速率越快，而应该说随机IOPS越高。

不过你的说法也有问题，即使无缓存，大条带下持续地的原因一般是测试软件的问题（如果卡/盘/操作系统没有问题的话），很多时候换个软件测试结果就正常了，或者直接硬盘复制数据的时候速度也是正常的。既然是持续了，就不存在你说的“按64K对齐的每次读取”了。

一般的说法，有缓存的情况，相当于把多次的磁盘读写合并了，因此理论上是条带越大性能越好。不过问题是缓存有一个命中率的问题，对于系统盘来说，大量的随机小文件读写操作，要能命中真的很难。写还好一点，读是完全没办法的。考虑到NTFS默认的簇大小是4K，因此理论上系统卷的条带大小最理想应该是4K/盘数，这样可以保证任何一个IO操作都能分布到所有磁盘上。不过问题又回来了，这样一碰到大文件的读写时，性能又下来了，毕竟系统盘也并不是只有小文件。因此一般的说法是系统盘16K～64K，数据盘（非数据库）越大越好（毕竟现在很少文件小于1M了，就算有，这种文件的性能一般也不太需要性能，除非是网站的网页，那个归到系统盘环境去）。但比较严谨的说法，都是说到底需要多大的条带，取决于实际应用的测试结果，这也是为什么RAID卡厂商提供多种选择的原因，否则如果能肯定说越大越好/越小越好，又或者有标准计算公式的话，直接在RAID卡上写死就好了。

至于你说的缓存大小/1024/盘数的说法，恕我见识少，从来没有听说过……

作者: bcyj 时间: 2009-6-4 06:08

我是说反了，正确应该是“条带越小的话，CPU占用率越高，持续速率越小，随机速率越快”，严格点来说不应该说随机速率越快，而应该说随机IOPS越高。

不过你的说法也有问题，即使无缓存，大条带下持续地的原因一 ...
harleylg 发表于 2009-6-4 05:50

你还是错了,IOPS也是小条带的低,在同样的盘之下,要提高iops,就是尽量让一次读取只经过一个盘,关于这个概率,请看这个帖子,我就不再写一次了http://we.pcinlife.com/thread-1148525-1-1.html
关于持续,这是软件实现问题
for(;;)
{
读取64k;
}
明白不?

作者: fishman 时间: 2009-6-4 06:14
无图无真相，建议lz把不同条带下的测试图发出来大家讨论。

作者: bcyj 时间: 2009-6-4 06:30
本帖最后由 bcyj 于 2009-6-4 06:33 编辑

预读缓存也基本不存在命中率的问题,因为这里不是CPU,没有条件跳转,不存在分支预测
卡做的预读就是在资源空闲时预读这次访问的下个块,本来就对随机读写没效,也就是只影响持续
关于你的“条带越小的话，CPU占用率越高，持续速率越小，随机速率越快”应该是“条带越小的话，CPU占用率越高，持续速率越大，随机速率不变,并发IO数越少”

作者: harleylg 时间: 2009-6-4 06:52

你还是错了,IOPS也是小条带的低,在同样的盘之下,要提高iops,就是尽量让一次读取只经过一个盘,关于这个概率,请看这个帖子,我就不再写一次了http://we.pcinlife.com/thread-1148525-1-1.html
bcyj 发表于 2009/6/4 06:08

我说的跟你那个帖子说的没有矛盾，我并不是说所有情况下都是小条带下IOPS高，我是说小条带的"随机IOPS"高……这个差很远的好不好？

至于你举的这个循环的例子，我只能说如果你是这样写的程序，操作系统并不一定就真的64K，64K这样去读取，很有可能：1、操作系统读取了1M，然后逐次给你64K的数据；2、操作系统每次读取4K，读取16次之后才给你返回。

作者: harleylg 时间: 2009-6-4 06:59

预读缓存也基本不存在命中率的问题,因为这里不是CPU,没有条件跳转,不存在分支预测
卡做的预读就是在资源空闲时预读这次访问的下个块,本来就对随机读写没效,也就是只影响持续
bcyj 发表于 2009/6/4 06:30

既然是缓存就一定有命中问题，即使不同于CPU的分支预测，RAID卡也有自己的缓存算法，不过就是最简单的顺序预测而已。但即使这样，因为往往同时不止一个IO产生，根据哪个IO去预读，预读多少块，也是有算法的。也不见得随机的时候就一定预读不中。

作者: bcyj 时间: 2009-6-4 07:06

我说的跟你那个帖子说的没有矛盾，我并不是说所有情况下都是小条带下IOPS高，我是说小条带的"随机IOPS"高……这个差很远的好不好？

至于你举的这个循环的例子，我只能说如果你是这样写的程序，操作系统并不一 ...
harleylg 发表于 2009-6-4 06:52

iops本来就是随机的,每个盘的iops都是相应固定的,所以理论上最高iops就是单盘的iops x 盘数,那么raid时要尽量靠近理论上的最高iops的方法,就是尽量让每次的io请求只由一个单独的盘去响应.条带越小,一次io请求由多盘响应的机会越大,iops越低(越接近单盘的iops)
关于例子,这只是一个例子,这里说的其实就是一个io请求的数据量,而不是上层的api

作者: bcyj 时间: 2009-6-4 07:09

既然是缓存就一定有命中问题，即使不同于CPU的分支预测，RAID卡也有自己的缓存算法，不过就是最简单的顺序预测而已。但即使这样，因为往往同时不止一个IO产生，根据哪个IO去预读，预读多少块，也是有算法的。也不 ...
harleylg 发表于 2009-6-4 06:59

不存在随机访问时命不命中的问题,因为根本没为随机访问去预读...
多并发io时,就是我上面说的"资源"

作者: 东方未明 时间: 2009-6-4 07:56
学习了

作者: harleylg 时间: 2009-6-4 08:23
本帖最后由 harleylg 于 2009-6-4 08:25 编辑

iops本来就是随机的,每个盘的iops都是相应固定的,所以理论上最高iops就是单盘的iops x 盘数,那么raid时要尽量靠近理论上的最高iops的方法,就是尽量让每次的io请求只由一个单独的盘去响应.条带越小,一次io请求由多盘 ...
bcyj 发表于 2009/6/4 07:06

原理上你说的没错，但是结论并不是必然的。举个极端的例子吧：
前提：4个硬盘组RAID 0，单盘性能：4k 200 IOPS/128k 100 IOPS，分别按照4k stripe size和 128k stripe size组成RAID 0
8K IOPS理论性能:4k stripe raid0: 200×4/2=400 IOPS，128k stripe RAID0:100*4/((128+15/2)/128)=378 IOPS

另外，在响应大文件IO的时候，其实小条带也并不会太吃亏，上面的例子里面，4k stripe raid0例子里面，4k是最小操作块大小，并不是最大操作块大小，如果响应一个读取8M的请求，RAID卡不会给每个物理硬盘8096/4/4=506个4k的IO请求，而是和128k stripe raid0一样，都是每个硬盘1个8096/4=2048k的IO请求。因为RAID卡本身有IO合并/分发的功能。

当然，如果都是128k的请求，128k stripe raid0肯定是完胜的。至于64k/32k，那还要看硬盘本身的16k/8k IOPS的性能，计算下来才知道。

另外，举的这个例子比较极端，到底应该大条带还是小条带，还是要看实际应用到底什么样的IO多一点。

最后，随机应用里面，也肯定有一定量的持续的，这种时候往往也会命中的。

作者: 含笑半步癫 时间: 2009-6-4 09:05
提示: 作者被禁止或删除内容自动屏蔽

作者: winddomain 时间: 2009-6-4 09:35
学习了，
另外如果是家用型主板的ICH7R以上做RAID5 HDTUNE 持续测试的时候图形跟山谷一样很可怕何解？

ICH9R和ICH10R上用2003 EE和2008 STD都做过测试结果是差不多的条带为128K

作者: res 时间: 2009-6-4 10:04
板载的就算了吧，R5性能很无语

作者: niub 时间: 2009-6-4 10:36
这个其实很简单,大有大的好,小有小的好,自己权衡,老看别人的干什么

作者: bcyj 时间: 2009-6-4 12:00
本帖最后由 bcyj 于 2009-6-4 12:24 编辑

原理上你说的没错，但是结论并不是必然的。举个极端的例子吧：
前提：4个硬盘组RAID 0，单盘性能：4k 200 IOPS/128k 100 IOPS，分别按照4k stripe size和 128k stripe size组成RAID 0
8K IOPS理论性能:4k stri ...
harleylg 发表于 2009-6-4 08:23

你以为每次访问文件都是从头访问到尾的(也就都是对齐的访问)?
你以为mft表里的内容也是全部对齐的?
你以为文件的附加权限控制也是对齐的?每个权限占一个簇?
你还是没有了解产生跨越的概率的问题,4k的stripe size,读写4k的数据,纯理论上,刚好位于一个簇里的机率是4k分之一.而按windows来说,实质上它都是按512(一个扇区)的大小来对齐读取的,那么刚好位于一个簇里的机率就是9分之一
4k stripe raid0: 200 × 4 / (4 * (1-0.11))=202 IOPS
128k stripe raid0:200 * 4 * ((256-16)/256)=744 IOPS

都说了很多次了,这个是一个理论概率问题,又拿什么8M的请求来说,如果一个请求大于stripe size的话,需要多盘响应的机率就是百分百了
就像大条带理论上的持续性能不如小条带的,但是由于卡上的预读缓存,实际上基本上没差别,而由于小条带占用卡的cpu比较高,有时候大条带持续更快.

最后,就是大的条带可以减低卡的运算量,让卡的运算能力不成为瓶颈.而预读缓存可以提高持续的性能,所以就在缓存大小和预读之间取个平衡,我第一个回帖那个公式就是根据实际测试结果来推导出来的比较合适日常家用的公式

作者: yj2001 时间: 2009-6-4 12:10
学习知识中.....

作者: bcyj 时间: 2009-6-4 12:12

学习了，
另外如果是家用型主板的ICH7R以上做RAID5 HDTUNE 持续测试的时候图形跟山谷一样很可怕何解？

ICH9R和ICH10R上用2003 EE和2008 STD都做过测试结果是差不多的条带为128K
winddomain 发表于 2009-6-4 09:35

因为ichx的raid5是软的raid5,用的是cpu做的xor运算,但是它要限制cpu的使用量,不可占用太多的时间片,同时他也没用大内存做缓存,所以就像山谷

作者: 拳头 时间: 2009-6-4 18:46
弄点软件做对比测试啊，不过很多时候的应用不好模拟，还是IOMETER比较适合做这方面测试。

作者: yphu 时间: 2009-6-4 22:41
争论了这么久一个图都没有？

作者: 含笑半步癫 时间: 2009-6-5 00:54
提示: 作者被禁止或删除内容自动屏蔽

作者: luckyps 时间: 2009-6-5 12:43
标记一下。。看的晕了。。
先看看楼主头像放松下

作者: 学步车 时间: 2009-6-5 12:57
这才是技术探讨嘛，高深，默默路过

作者: gz0921 时间: 2009-6-5 13:08
这个帖子要留意下名了~~

作者: harleylg 时间: 2009-6-5 15:06

你以为每次访问文件都是从头访问到尾的(也就都是对齐的访问)?
你以为mft表里的内容也是全部对齐的?
你以为文件的附加权限控制也是对齐的?每个权限占一个簇?
你还是没有了解产生跨越的概率的问题,4k的stripe siz ...
bcyj 发表于 2009/6/4 12:00

恩，我的那个公式计算的确有问题，而且举的例子不对。

重新复习了一下，另外找了份评测的数据：

（来源：中关村在线，原文地址：http://memory.zol.com.cn/133/1332758.html
取其中希捷7200.12 1TB的测试数据。
假设4个硬盘组RAID0，Stripe Size取8K，那么4K时候的理论随机IOps：
1、按照512B对齐，Stripe Size=8K的时候有16种对齐方式，其中9种情况在1个硬盘上，7种情况在两个硬盘上，因此每个IO的实际物理响应IO数应该是（1×9+2×7）/16=1.4375，因此RAID0的4k随机IOps为70.34×4/1.4375=195.72
同样的道理，计算出来其他Stripe Size的IOps为
Stripe Size：8K__________32K_________128K_________512K
2K IOps:    236.93_______264.59______253.90________209.46
4k IOps:    195.73_______249.69______250.04________208.65
8K IOps:    145.22_______224.41______242.66________207.05

其他的也一样分析计算，可以看到就随机读取来说，并没有一个最优值，4K/8K的时候128K Stripe Size的性能最优，2K的时候是32K Stripe Size最优。更加不是你所说的越大越好，假设有支持512K Stripe Size的话。所以到底应该用多大的Stripe Size，还是要看实际的应用。

作者: harleylg 时间: 2009-6-5 15:22
补充一下：如果换成西数黑盘的话，4K的时候也是32K Stripe Size的IOps更高一点。具体计算我就不重复了。

作者: bcyj 时间: 2009-6-5 16:10

恩，我的那个公式计算的确有问题，而且举的例子不对。

重新复习了一下，另外找了份评测的数据：

（来源：中关村在线，原文地址：http://memory.zol. ...
harleylg 发表于 2009-6-5 15:06

你第一步就错了,"按照512B对齐，Stripe Size=8K的时候有16种对齐方式，其中9种情况在1个硬盘上"
512B对齐,Stripe Size=8K,那其实就是把一个Stripe Size分成 16块,读取8K的数据,就是读取16块,
两个盘的话,就是在32块里读取连续的16块,在不跨盘的情况就只有1-16和17-32这2种读取方式,其它的2-17,3-18直到16-31这14种都是跨越的了

作者: harleylg 时间: 2009-6-5 16:15

你第一步就错了,"按照512B对齐，Stripe Size=8K的时候有16种对齐方式，其中9种情况在1个硬盘上"
512B对齐,Stripe Size=8K,那其实就是把一个Stripe Size分成 16块,读取8K的数据,就是读取16块,
两个盘的话,就是在3 ...
bcyj 发表于 2009/6/5 16:10

8K Stripe Size,一共有16块512B，读取4K数据：
数据位置：1～8，2～9，3～10，……，9～16，一共9种情况在同一个盘上。10～17,11~18,……16～23，一共7种情况。MS我没有错吧？

作者: bcyj 时间: 2009-6-5 16:31

8K Stripe Size,一共有16块512B，读取4K数据：
数据位置：1～8，2～9，3～10，……，9～16，一共9种情况在同一个盘上。10～17,11~18,……16～23，一共7种情况。MS我没有错吧？
harleylg 发表于 2009-6-5 16:15

错了,如果是4k的话也错了1-8直到9-16,然后17-24直到25-32,18种

作者: harleylg 时间: 2009-6-5 16:39

错了,如果是4k的话也错了1-8直到9-16,然后17-24直到25-32,18种
bcyj 发表于 2009/6/5 16:31

呃，17～24跟1～8有什么不同么？
就算按照你的算法，两个8K Stripe也一共有32种对齐方式，18种在同一个硬盘上，跟我说的16种对齐方式，9种在同一个硬盘上有什么不同么？

作者: bcyj 时间: 2009-6-5 16:57
本帖最后由 bcyj 于 2009-6-5 17:10 编辑

不同的,你的计算公式"（1×9+2×7）/16=1.4375"的错误在于把另一个盘的16块的双盘的机率计算了,但是没算那个盘的单盘的机率
简单说就是分母的不同,正确的应该是 1 + (7/(7+18))/2 = 1.14
验证如下
x为单盘iops,现在计算的是双盘
x * 2 * 18/25 + x * 7 / 25 = x * 2 / ( 1 + (7/(7+18))/2 )

作者: harleylg 时间: 2009-6-5 17:16
我又不是算一个盘的单/双盘几率，我算的是一个4K IO的物理IO几率……
就算按照你的方法算，4盘是8K×4/512B=64种对齐，
HDD1：1～8，2～9，……9～16
HDD2：17～24，18～25，……25～32
HDD3：33～40，34～41，……41～48
HDD4：49～56，50～57，……57～64
一共9×4=36种情况都是单盘，剩余28种情况都是双盘，
1×36/64+2×28/64=1.4375

你的算法问题在于你取了两个Stripe，一共有32种对齐情况，但你只取了这4K分布在这两个Stripe里面1～8，2～9，……，25～32一共25种情况。但事实上，如果是双盘RAID0的话，还有26～32+1，27～32+1～2，……，32+1～7这7种情况没算。三盘以上RAID0的话，那就是26～33，27～34，……，32～39。

难道说，这4K一定不会从26～32这7个位置开始？

作者: bcyj 时间: 2009-6-5 17:32
从26～32这7个位置开始,一样的,因为下一个区间又是第一个盘了,这个是单盘响应的机率

作者: harleylg 时间: 2009-6-5 17:38
既然下一个区间是第一个盘，26～32本身在第二个盘上，何来单盘响应一说？

作者: bcyj 时间: 2009-6-5 17:38
1-16和17-32之间单盘读的机率是7/25,17-32和33-49之间单盘读的机率还是7/25
因为只可能发生一次跨越,明白不?
注意(7/(7+18))/2这个除以2

作者: harleylg 时间: 2009-6-5 17:44
不过好像我的计算还是有问题，不能那么算……

还是那份数据，按照希捷7200.12，8K Stripe Size，4K IO响应……
应该是9种情况单盘：IOps=70.34×4=281.36 IOps，
7种情况双盘：IOps=70.34×4/2=140.68 IOps，
平均IOps应该是（281.36×9+140.68×7）/16=219.81 IOps

作者: harleylg 时间: 2009-6-5 17:58

1-16和17-32之间单盘读的机率是7/25,17-32和33-49之间单盘读的机率还是7/25
因为只可能发生一次跨越,明白不?
注意(7/(7+18))/2这个除以2
bcyj 发表于 2009/6/5 17:38

我知道只能发生一次跨越，毕竟Stripe Size 8K，Data Size 4K，不可能发生两次跨越。
之所以发生跨越，是因为4K Data的起始位置可能在8K Stripe按照512B划分的16个块里面的任何一个位置，当起始位置处于9以后（不包括9）的时候就发生跨越了。
这是只看一个Stripe的情况。如果你要看两个Stripe的话，那么是一共32个可能的起始位置，当起始位置位于25以后（不包括25）的时候，也必然会发生跨越的。

这个是Adaptec网站上的一篇文章，http://storageadvisors.adaptec.c ... -right-stripe-size/
文章里面举的刚好就是8K Stripe，4K请求的情况，按照你的方法，是计算不出625 IOps的那个结果的。

作者: 含笑半步癫 时间: 2009-6-5 18:07
提示: 作者被禁止或删除内容自动屏蔽

作者: harleylg 时间: 2009-6-5 18:23

看了半天看不懂楼上两位在说什么。。。唉。。。。

其实我的问题很简单

我是dell p5i 的卡 512M缓存，，，两块富士通MAY的36G小硬盘

单盘寻道7ms，，持续55M

现在我用这两块硬盘做RAID0，做系统盘只装WIN ...
含笑半步癫发表于 2009/6/5 18:07

其实我跟黄脸一开始的争论是条带大小对性能的影响，我的主观点是不同的应用结果不同，不过我最开始的其中一个观点“条带越小，IOPS越高”肯定是错误的，后来的讨论就是怎么计算RAID的IOPS了……

回到你的问题，最精确的方法应该是系统/软件装好之后，做一个Ghost。
然后设置不同条带大小的RAID，Ghost回去，记录开机/关机，以及其他你自己最常用的操作所需的时间。最后对比各个结果。

懒一点的，另外找一个硬盘装一个PC Mark Vantage，测试不同条带时候的HDD分数。我是建议看Vista启动/应用程序载入/游戏载入三项。

作者: dxa112 时间: 2009-6-5 18:25
进来学习下,看了半天，，还是一头雾水

作者: 含笑半步癫 时间: 2009-6-5 18:30
提示: 作者被禁止或删除内容自动屏蔽

作者: bcyj 时间: 2009-6-5 18:34

我知道只能发生一次跨越，毕竟Stripe Size 8K，Data Size 4K，不可能发生两次跨越。
之所以发生跨越，是因为4K Data的起始位置可能在8K Stripe按照512B划分的16个块里面的任何一个位置，当起始位置处于9以后（不 ...
harleylg 发表于 2009-6-5 17:58

现在有时间认真想了,这个机率的确是我错了,不过如果要精确算,还要算上带条的数目了,因为第一个和最后一个没有跨越,那公式改正为:
x为单盘iops,y为跨越的机率,现在计算的是双盘
x * 2 * (1-y) + x * y

作者: harleylg 时间: 2009-6-5 18:37

不过好像我的计算还是有问题，不能那么算……

还是那份数据，按照希捷7200.12，8K Stripe Size，4K IO响应……
应该是9种情况单盘：IOps=70.34×4=281.36 IOps，
7种情况双盘：IOps=70.34×4/2=140.68 IOps，
...
harleylg 发表于 2009/6/5 17:44

按照这个计算方法，ST7200.12的四盘RAID0 IOps应该是
条带大小：8K_______32K_______128K______512K
1K 请求： 272.57____274.84____256.38____209.98
2K 请求： 254.98____270.51____255.37____209.77
4K 请求： 219.81____261.85____253.37____209.36
8K 请求： 149.47____244.54____249.35____208.54

西数黑盘1T的四盘RAID0 IOps：
条带大小：8K_______32K_____128K_____512K
1K请求：312.17____313.85___282.25___218.25
2K请求：292.03____308.91___281.14___218.04
4K请求：251.75____299.02___278.93___217.61
8K请求：171.19____279.25___274.51___216.76

作者: bcyj 时间: 2009-6-5 18:42

看了半天看不懂楼上两位在说什么。。。唉。。。。

其实我的问题很简单

我是dell p5i 的卡 512M缓存，，，两块富士通MAY的36G小硬盘

单盘寻道7ms，，持续55M

现在我用这两块硬盘做RAID0，做系统盘只装WIN ...
含笑半步癫发表于 2009-6-5 18:07

5i的卡,512缓存,双盘,开自适应预读,实测结果128K以上的条带差别都不大

作者: harleylg 时间: 2009-6-5 18:44

现在有时间认真想了,这个机率的确是我错了,不过如果要精确算,还要算上带条的数目了,因为第一个和最后一个没有跨越,那公式改正为:
x为单盘iops,y为跨越的机率,现在计算的是双盘
x * 2 * (1-y) + x * y
bcyj 发表于 2009/6/5 18:34

恩，如果是多盘的话，引入盘数z，那么请求大小<=条带大小的话，应该是
x*z*(1-y)+x*z/2*y

作者: bcyj 时间: 2009-6-5 18:45

按照这个计算方法，ST7200.12的四盘RAID0 IOps应该是
条带大小：8K_______32K_______128K______512K
1K 请求： 272.57____274.84____256.38____209.98
2K 请求： 254.98____270.51____255.37____209.77
4K ...
harleylg 发表于 2009-6-5 18:37

不论多大的数据请求,都应该条带越大,单盘读的机会越大,不可能大条带反而低了的

作者: harleylg 时间: 2009-6-5 18:50

5i的卡,512缓存,双盘,开自适应预读,实测结果128K以上的条带差别都不大
bcyj 发表于 2009/6/5 18:42

5i没用过，不过我就是记得以前4i带一对MAU的时候，32K>64K>128K才跟你争论的……不过的确是差的不是很多……

作者: bcyj 时间: 2009-6-5 18:52

5i没用过，不过我就是记得以前4i带一对MAU的时候，32K>64K>128K才跟你争论的……不过的确是差的不是很多……
harleylg 发表于 2009-6-5 18:50

你这个说的是iops还是持续,你的4i缓存多大

作者: harleylg 时间: 2009-6-5 19:01

不论多大的数据请求,都应该条带越大,单盘读的机会越大,不可能大条带反而低了的
bcyj 发表于 2009/6/5 18:45

问题是条带大了之后，不管实际请求的IO是多少，每次物理IO都是最小按照条带大小请求的，而单个硬盘一般都是请求越大，IOps越低。
也就是说即使请求的是4K的数据，如果条带大小是128K的话，那么实际的IOps是按照128K的IOps计算的，所以会导致条带大了之后IOps反而变低的情况出现。

作者: harleylg 时间: 2009-6-5 19:03

你这个说的是iops还是持续,你的4i缓存多大
bcyj 发表于 2009/6/5 18:52

随机IOps，4e/DC，标配128MB

作者: bcyj 时间: 2009-6-5 19:15

问题是条带大了之后，不管实际请求的IO是多少，每次物理IO都是最小按照条带大小请求的，而单个硬盘一般都是请求越大，IOps越低。
也就是说即使请求的是4K的数据，如果条带大小是128K的话，那么实际的IOps是按照 ...
harleylg 发表于 2009-6-5 19:01

不是这样的,不会按条带大小来放大请求的,放大请求的只有预读缓存才会,我现在用8888加两上x25-e,用1M的条带
如果是用条带大小来请求的话,就是4k的会变成1M来读,放大了256倍,那我的随机4k速度应该就只有持续的256分之一,但我现在的4k随机是80M(开的是自适应预读,也就是在连续两个相邻请求的时才开始预读),那我的持续应该是80M * 256 = 20480M,明显错误

作者: bcyj 时间: 2009-6-5 19:20

随机IOps，4e/DC，标配128MB
harleylg 发表于 2009-6-5 19:03

你应该是预读缓存开了总是预读,开自适应就不会了,你试试吧

作者: Cycle 时间: 2009-6-5 19:22
raid的设置。。。貌似需要很复杂的计算。
条带设置跟实际的应用关系很大。
文件服务器和数据库服务器、应用服务器的设置是2回事。
至于日常应用领域。。。没研究~

作者: bcyj 时间: 2009-6-5 19:25
http://we.pcinlife.com/thread-1148525-1-1.html
看看拳头的1M条带的测试结果

作者: harleylg 时间: 2009-6-5 19:46

不是这样的,不会按条带大小来放大请求的,放大请求的只有预读缓存才会,我现在用8888加两上x25-e,用1M的条带
如果是用条带大小来请求的话,就是4k的会变成1M来读,放大了256倍,那我的随机4k速度应该就只有持续的256分 ...
bcyj 发表于 2009/6/5 19:15

难道说Stripe不是RAID控制器的最小读写单位？还是说现在的RAID卡都有自适应读取了？
恩，我的4e/DC有可能开了总是预读，不过卡早出了，没法再试了。

不过如果小文件的随机IOps都是大条带胜出的话，小条带还有什么存在意义么？

作者: harleylg 时间: 2009-6-5 19:50
另外，现在用的x25-M和前阵子用的GSkill SSD，用板载RAID，跑PC Mark也是32k>64k>128k，这个又怎么解释呢？还是说就是因为小文件也分布的更碎，而且IO负担还未成为瓶颈，所以这时候小条带的性能更好？

作者: bcyj 时间: 2009-6-5 19:51

难道说Stripe不是RAID控制器的最小读写单位？还是说现在的RAID卡都有自适应读取了？
恩，我的4e/DC有可能开了总是预读，不过卡早出了，没法再试了。

不过如果小文件的随机IOps都是大条带胜出的话，小条带还有 ...
harleylg 发表于 2009-6-5 19:46

本来就算理论上小条带也就是持续性能好,随机iops一直是大条带优胜,每点可以在任何一条raid的说明书上找到
就是由于这样,现在卡支持的条带才越来越大

作者: bcyj 时间: 2009-6-5 19:52
本帖最后由 bcyj 于 2009-6-5 19:53 编辑

另外，现在用的x25-M和前阵子用的GSkill SSD，用板载RAID，跑PC Mark也是32k>64k>128k，这个又怎么解释呢？还是说就是因为小文件也分布的更碎，而且IO负担还未成为瓶颈，所以这时候小条带的性能更好？
harleylg 发表于 2009-6-5 19:50

pc mark基本上就是一个单io的持续和随机的测试,它最高iops占用不过10..
而板载RAID没缓存,小条带的持续当然性能要好一些

作者: 含笑半步癫 时间: 2009-6-6 22:37
提示: 作者被禁止或删除内容自动屏蔽

作者: fly-fox 时间: 2009-6-9 21:03
只想说两点：
一、RAID0、5、6下面，不考虑存储系统带宽，盘越多，性能越好；
二、大量的小文件，用小的Strip Size，大文件就用大的Strip Szie，跟Oracle里面，OLTP用小的Block Size，OLAP用大的Block Size的道理是一样的。

作者: bcyj 时间: 2009-6-10 08:47

只想说两点：
一、RAID0、5、6下面，不考虑存储系统带宽，盘越多，性能越好；
二、大量的小文件，用小的Strip Size，大文件就用大的Strip Szie，跟Oracle里面，OLTP用小的Block Size，OLAP用大的Block Size的道理是 ...
fly-fox 发表于 2009-6-9 21:03

你没认真看完这个帖子，所以你的看法完全错误，请重新看

作者: fly-fox 时间: 2009-6-10 09:21

你没认真看完这个帖子，所以你的看法完全错误，请重新看
bcyj 发表于 2009-6-10 08:47

首要的问题是你是否认可对于RAID0，是不是盘数越多，性能越好（先不说RAID5，也不考虑系统带宽）？

作者: bcyj 时间: 2009-6-10 09:43

首要的问题是你是否认可对于RAID0，是不是盘数越多，性能越好（先不说RAID5，也不考虑系统带宽）？
fly-fox 发表于 2009-6-10 09:21

raid0的总体性能当然越多盘越好（寻道性能不变，持续和iops更加）
但这个和你的错误的观点根本不是一个点上的东西，请重新从头到尾认真看那两个帖子，理论已经说的很详细了，第一个帖子是主要讨论持续速度的，第二个帖子主要就是iops

欢迎光临 POPPUR爱换 (https://we.poppur.com/)