POPPUR爱换

标题: 建立RAID时，条带设定的比较大有什么不好？ [打印本页]
作者: 拳头    时间: 2009-4-22 14:52
标题: 建立RAID时，条带设定的比较大有什么不好？
理论上说，条带深度设定的比较小的时候能增加单个用户读写文件的速度，而条带设定的比较大有利于多用户的并发操作，我在6i的RAID上似乎看不出这么明显的差别，而将条带深度设定到1MB时无论是单个大或小文件的读写还是多用户并发都比小条带的好，但不知道条带设定的大了有什么其他的弊端？
作者: stephenmaxmax    时间: 2009-4-22 18:27
我以前版载用最大，开始跑分很快，后来实际用感觉盘越满速度越慢。后来换了默认的优化值，感觉比较平均了
作者: 拳头    时间: 2009-4-22 22:06
是啊，我用IOMETER测，都是条带越大测试结果越好，觉得不会这么简单
作者: w1972    时间: 2009-4-22 22:14
提示: 作者被禁止或删除 内容自动屏蔽
作者: zhdick    时间: 2009-4-22 22:21
条带大的话，小文件性能急剧下降。
条带小的话，大文件性能不如意。
作者: bcyj    时间: 2009-4-22 22:23
本帖最后由 bcyj 于 2009-4-23 01:49 编辑

目前来说条带是固定的，就是说如果是1M的条带,两盘raid 0,1盘的0-1M就是逻辑盘上0-1M,2盘的0-1M就是逻辑盘上1-2M.如果我连续写入0-1M 2-3M 4-5M这样间隔1M的1M的内容，就变成单盘操作了．1M的条带，那写入连续的512K数据，就有2分1的机会是单盘读写．512K的条带就变成4分1是单盘读写了．条带小就是纯概率上读写分散度高,所以在目前主流的磁盘格式下，选连续读写时，相对可以达到最高速度的块来做条带，应该能得到理论上最高的性能，应该就是512K左右
作者: bcyj    时间: 2009-4-22 22:34
条带大的话，小文件性能急剧下降。
条带小的话，大文件性能不如意。
zhdick 发表于 2009-4-22 22:21

现在的卡和盘都有大缓存，还有ncq和tcq，大条带导致的小文件性能的下降已经比过去减少很多，只有在读写间隔条带的大量小文件以使缓存溢出时，才有性能的下降，这概率实在太低了
作者: w1972    时间: 2009-4-22 22:36
提示: 作者被禁止或删除 内容自动屏蔽
作者: kkk8    时间: 2009-4-22 23:10
这个问题已经有人深入研究过了，具体在哪里忘记了，只记住结论：对PERC 5i,6i，绝大多数情况下128k的条带性能是最好的
作者: cmjohncheng    时间: 2009-4-22 23:13
印象中,如果条带大会浪费系统空间,如果条带1MB,文件只有512k,系统也会用1MB的空间来存放那个512k的文件(有错请纠正) .
作者: bcyj    时间: 2009-4-22 23:17
印象中,如果条带大会浪费系统空间,如果条带1MB,文件只有512k,系统也会用1MB的空间来存放那个512k的文件(有错请纠正) .
cmjohncheng 发表于 2009-4-22 23:13

这个是磁盘格式上的逻辑分配单位大小，就是"簇"，不是条带.另ntfs上有mft用来存放小文件，簇大小浪费的空间已经很少了
作者: afeifish    时间: 2009-4-22 23:21
楼上大黄脸是高手，学习了
作者: visa_fine    时间: 2009-4-23 00:56
进来学习啊


顺拜一下高手
作者: 拳头    时间: 2009-4-23 13:04
印象中,如果条带大会浪费系统空间,如果条带1MB,文件只有512k,系统也会用1MB的空间来存放那个512k的文件(有错请纠正) .
cmjohncheng 发表于 2009-4-22 23:13

这个问题我也曾经怀疑过，但实际上条带上每个硬盘的那个区间不是只存放一个小文件后剩余的部分就浪费了，而是继续放其他的文件，我用1000个1024B的小文件存到1MB的RAID盘上，结果是1M的文件占用4M的空间（NTFS的簇为4K），而不是1G（条带深度是1MB）或256MB（条带长度是1MB，4个盘，那深度就是256KB）
作者: 拳头    时间: 2009-4-23 13:06
5I、6I的STRIPE SIZE到底是条带长度还是深度？中文的管理软件是“条带大小”，对应正规的说法就是条带长度，而英文的“STRIPE SIZE”则是指条带深度，两者关系是条带长度=深度X盘数。
作者: 拳头    时间: 2009-4-23 13:11
我用IOMETER来测试512B到512KB的数据块在1~256个并发IO下的表现，条带大小分别设定为8K、32K、128K、512K和1MB，结果很奇怪的就是1MB的最好，无论是512B的小数据还是512KB的大块，无论是1IO还是256并发的IO。
盘是4个7200.11 160G，3天了不停的测试，快晕倒了。
作者: mm740    时间: 2009-4-23 13:12
有FASTCOPY了，条带当然越大越好就用128KB！
作者: 拳头    时间: 2009-4-23 14:16
越大越好应该用1MB的条带啊
作者: cmjohncheng    时间: 2009-4-23 14:22
18# 拳头 普通板载RAID晶片只支援最大128kb而已~
作者: bcyj    时间: 2009-4-23 14:26
我用IOMETER来测试512B到512KB的数据块在1~256个并发IO下的表现，条带大小分别设定为8K、32K、128K、512K和1MB，结果很奇怪的就是1MB的最好，无论是512B的小数据还是512KB的大块，无论是1IO还是256并发的IO。
盘是4 ...
拳头 发表于 2009-4-23 13:11

5i 6i的是STRIPE SIZE，这个直接读一下单盘数据就很容易得知.
原来你的是sata的盘，那1m的条带性能最好就不出奇了,你测一下单盘的,看看是不是1m的数据块的持续存取性能最高吧.
作者: bcyj    时间: 2009-4-23 14:50
这个问题我也曾经怀疑过，但实际上条带上每个硬盘的那个区间不是只存放一个小文件后剩余的部分就浪费了，而是继续放其他的文件，我用1000个1024B的小文件存到1MB的RAID盘上，结果是1M的文件占用4M的空间（NTFS的簇 ...
拳头 发表于 2009-4-23 13:04

如果你这样怀疑过，说明你对带条的概念不清晰．条带只是阵列上分割逻辑单元到物理盘片的一个参数:
物理磁盘 = 逻辑LBA * 扇区size /  带条size
物理磁盘LBA = (逻辑LBA * 扇区size) % 带条size
这个与磁盘文件系统格式完全没关系，而文件是存放在文件系统上的，跟本不是一个层一个单位上的东西
作者: scowl    时间: 2009-4-23 16:28
现在的卡和盘都有大缓存，还有ncq和tcq，大条带导致的小文件性能的下降已经比过去减少很多，只有在读写间隔条带的大量小文件以使缓存溢出时，才有性能的下降，这概率实在太低了
bcyj 发表于 2009-4-22 22:34



缓存跟条带有什么关系？？

条带是强制分割的

我打很简单一个比方

比如你有一个4硬盘的RAID0   划分1M的条带

现在有10个用户同时写入10个100K的文件    结果就是这10个文件全写进了1个硬盘    其他三个硬盘完全是闲着的

因为要先把一个条带写满了   才会写下一个条带

所以   有大量小文件随机读写的场合   条带绝对不能大   不然性能下降非常厉害


总体来说  

小的条带   对大文件读写的影响很小    只不过占用CPU资源高一点   IO操作次数多一些

但是大的条带    对小文件的读写影响很大
作者: cmjohncheng    时间: 2009-4-23 16:37
那装Windows系统(XP,Vista,7)，一般多大比较适合呢？网上看，一般的说法是32k比较理想，真的是这样吗？
作者: DragonHeart    时间: 2009-4-23 17:25
华硕主板说明书上的说法是：

如果你用来做服务器，那条带大小应该小一点。
如果你用来做视音频编辑，那条带大小应该大一点。
作者: whateveru    时间: 2009-4-23 17:33
22# scowl

看来raid还有智能化提升的空间,例如动态、自适应条带.....
作者: bcyj    时间: 2009-4-23 19:07
缓存跟条带有什么关系？？

条带是强制分割的

我打很简单一个比方

比如你有一个4硬盘的RAID0   划分1M的条带

现在有10个用户同时写入10个100K的文件    结果就是这10个文件全写进了1个硬盘    其他 ...
scowl 发表于 2009-4-23 16:28

你先看完我在这个帖子里的所有回复，你对条带的理解有问题
作者: bcyj    时间: 2009-4-23 19:19
4硬盘的RAID0   划分1M的条带，一个100k的文件全在单一个磁盘上的机会是2分之1(带条比文件大时，不论多少盘raid0,机率都是2分之1,原因自己画图)，10个文件全在一个磁盘上就是2的十次方分之1,就算全在一个磁盘上，由于有缓存，这1m也就是写入了缓存罢了．如果有1000个100k的文件，也就是100M的数据罢了．而tcq或ncq对于写入的数据进行排序，有很大的机率在卡的缓存中合并作为大的操作块来对磁盘进行读写，那写小文件的性能就与持续性能接近了．over
作者: 拳头    时间: 2009-4-23 19:31
华硕主板说明书上的说法是：

如果你用来做服务器，那条带大小应该小一点。
如果你用来做视音频编辑，那条带大小应该大一点。
DragonHeart 发表于 2009-4-23 17:25

你确认没有记错吗？因为和任何一本书上说的理论刚好相反了。
作者: 拳头    时间: 2009-4-23 19:42
5i 6i的是STRIPE SIZE，这个直接读一下单盘数据就很容易得知.
原来你的是sata的盘，那1m的条带性能最好就不出奇了,你测一下单盘的,看看是不是1m的数据块的持续存取性能最高吧.
bcyj 发表于 2009-4-23 14:26

单盘没必要去测试了吧？既然说是做RAID，也应该有2块或者更多，单硬盘做RAID只是阵列卡的特例，实际上没有什么意义，不过回头我试试看是不是有影响。
作者: 拳头    时间: 2009-4-23 19:42
22# scowl

看来raid还有智能化提升的空间,例如动态、自适应条带.....
whateveru 发表于 2009-4-23 17:33

关于读写策略优化的内容很多，但似乎成熟的也就是这几种。
作者: bcyj    时间: 2009-4-23 19:50
单盘没必要去测试了吧？既然说是做RAID，也应该有2块或者更多，单硬盘做RAID只是阵列卡的特例，实际上没有什么意义，不过回头我试试看是不是有影响。
拳头 发表于 2009-4-23 19:42

有必要的，不需要在raid上测．硬盘的读写不同大小的块的性能是不一样的，就像是读写4k的块时性能特别低一样．在raid0上，单盘的连续读写，其实就是每个硬盘按带条大小的分块读写
作者: 拳头    时间: 2009-4-23 19:56
我打很简单一个比方

比如你有一个4硬盘的RAID0   划分1M的条带

现在有10个用户同时写入10个100K的文件    结果就是这10个文件全写进了1个硬盘    其他三个硬盘完全是闲着的

因为要先把一个条带写满了   才会写下一个条带

所以   有大量小文件随机读写的场合   条带绝对不能大   不然性能下降非常厉害

...
scowl 发表于 2009-4-23 16:28


我觉得在服务器要面对的多用户IO操作方面，读写速度没有响应时间来的重要，同样打比方，一个IO是4X128KB的持续写入，如果所有的4块硬盘都去响应这个IO（每个分128KB，条带深度也刚好是128KB），写入速度是很快，而且完成这个IO的时间也变小，但其他用户的IO即使很小，比如只有512B，也被耽搁了，导致平均响应时间变长，这是服务器不能允许的，所以将条带设定的较大是为了避免某个IO长时间占用多个硬盘，比如每个盘的条带深度都是1MB，那个4X128KB都写到一个盘导致时间增加，但其他IO都得到了及时的执行，才符合多用户的环境。
作者: 拳头    时间: 2009-4-23 20:05
有必要的，不需要在raid上测．硬盘的读写不同大小的块的性能是不一样的，就像是读写4k的块时性能特别低一样．在raid0上，单盘的连续读写，其实就是每个硬盘按带条大小的分块读写
bcyj 发表于 2009-4-23 19:50

嗯，是会有影响，等于大数据被阵列卡人为划分成小的IO了，不过从这个观点看，也应该是将条带设定的越大越好啊，大条带深度时，大数据被分割成较少的数据块，每个硬盘的读写速度比较高，小数据即使不能同时写到每个盘上也能按单个硬盘的读写进行操作；相反，小条带将原来就小的数据分割的更小，如果都分到一个盘上去读写会导致速度更慢，只能靠分到不同盘上去读写来改善
作者: 拳头    时间: 2009-4-23 20:11
现在的卡和盘都有大缓存，还有ncq和tcq，大条带导致的小文件性能的下降已经比过去减少很多，只有在读写间隔条带的大量小文件以使缓存溢出时，才有性能的下降，这概率实在太低了
bcyj 发表于 2009-4-22 22:34

NCQ等优化是从操作系统的角度来进行优化的，不过有些奇怪，我将SATA硬盘接南桥上，开NCQ后1~256个用户的随机小数据IOPS是线性增加的，1用户只有80，远比SAS盘低，但256个IO同时并发时测试结果就有150IOPS了。
将SATA接6i上，8个以上的IO并发的IOPS就不再增加，结果是256并发下还不如INTEL的ICH8R南桥。
感觉NCQ不能与RAID卡配合实现优化，或者在RAID卡上将这种优化结果给抹除了，RAID卡与硬盘之间的接口目前有NCQ这种优化吗？应该没有吧，有的是读写策略优化。
作者: bcyj    时间: 2009-4-23 20:14
嗯，是会有影响，等于大数据被阵列卡人为划分成小的IO了，不过从这个观点看，也应该是将条带设定的越大越好啊，大条带深度时，大数据被分割成较少的数据块，每个硬盘的读写速度比较高，小数据即使不能同时写到每个 ...
拳头 发表于 2009-4-23 20:05

是呀，我的观点也是设的大的比较好．不过在数据分块大到一定的程度，再大，性能就也不会提高了
作者: bcyj    时间: 2009-4-23 20:17
本帖最后由 bcyj 于 2009-4-23 20:22 编辑
NCQ等优化是从操作系统的角度来进行优化的，不过有些奇怪，我将SATA硬盘接南桥上，开NCQ后1~256个用户的随机小数据IOPS是线性增加的，1用户只有80，远比SAS盘低，但256个IO同时并发时测试结果就有150IOPS了。
将S ...
拳头 发表于 2009-4-23 20:11

这个其实就是ncq的效果了，操作系统为了减少碎片出现的可能性．每个用户在磁盘上操作时分的块是比较分散的．
而同一个用户，操作距离是比较近的，距离比较近的,ncq就可能排序合并块一个io来读写了．
ncq tcq不是操作系统的，应该是sata或sas控制器里的指令排序.
作者: bcyj    时间: 2009-4-23 20:20
6i的sata性能不行，我也有这个感觉，5i相对于来说还好一点.但是还是没有ich8 9好，就和ich10差不多．
作者: 拳头    时间: 2009-4-23 20:25
请问一下bcyj，条带长度=划过所有硬盘的条带的总字节数，条带深度=一个条带在某个硬盘上的区域的字节数，那STRIPE SIZE是指条带深度还是长度？其他论坛有人说是长度，但如果8KB的条带长度只有3个硬盘，每个盘的条带深度岂不是注定无法一样大？因为8K不能被3除尽，因此也有网友说如果条带长度为8K而硬盘是3个，具体的深度可能就变成3K，实际的条带长度就变成3KX3=9KB了，
想知道RAID卡的具体的条带深度是可以根据应用具体的去设定条带深度的大小，而不是只取经验值。
作者: bcyj    时间: 2009-4-23 20:29
应该是指深度,我目前还没有见过按长度设置的卡．要看到底STRIPE SIZE是多大，直接做raid，写入一下数据，然后在单盘上读取一下看看按什么大小分割就行．恢复raid数据时常用．
作者: liu-88    时间: 2009-4-26 20:25
学习。。。
作者: whut123456    时间: 2009-4-27 04:00
狂佩服大黄脸。。  学习中。。
作者: Jankanwoo    时间: 2009-4-27 07:24
好文啊,mark之
作者: frank77    时间: 2009-4-27 08:13
RAID要看用途来设定条带大小，如果安装系统就用小的，如果用来存储数据（电影、游戏镜像等）就用大的。
作者: fishman    时间: 2009-4-27 09:49
这个问题也遇到过。我一直用的hp(compaq)系列卡，从431到5302到6402，在ACU里有说明，比较小的64k以下stripe size对小文件读写有利，256k以上比较大的stripe size对大文件读写有利，默认的128k属于平衡型方案。但我自己测试也是越大性能越好，所以一直用的acu允许的最大值。另外同样的几个盘组建r0 r5 r6允许设置的stripe size是不同的，raid等级越高，允许的stripe size越小。
作者: 方丈    时间: 2009-4-30 02:21
做个记号备用
作者: 拳头    时间: 2009-4-30 08:51
这个问题也遇到过。我一直用的hp(compaq)系列卡，从431到5302到6402，在ACU里有说明，比较小的64k以下stripe size对小文件读写有利，256k以上比较大的stripe size对大文件读写有利，默认的128k属于平衡型方案。但我自 ...
fishman 发表于 2009-4-27 09:49

晚上下个新固件后再对比一下，觉得这些现象也许是阵列卡固件或者其他方面相互配合时产生的特例
作者: idolclub    时间: 2009-5-4 23:23
请问一下bcyj，条带长度=划过所有硬盘的条带的总字节数，条带深度=一个条带在某个硬盘上的区域的字节数，那STRIPE SIZE是指条带深度还是长度？其他论坛有人说是长度，但如果8KB的条带长度只有3个硬盘，每个盘的条带深 ...
拳头 发表于 2009-4-23 20:25

Stripe Width 是由陣列(Array) 的硬件組成部份來決定，陣列的其中一個特點就是可把數據代整為零，把一個大數據細分成多份小數據同時存入硬盤中以提升整體讀寫效能，Stripe Width 的數值就相當於數據初分開的份數，這個數值是由硬件(或硬盤)來決定的，在建立陣列時就已被確定下來，除非重新建立陣列否則這個數值不會被改動。

例如 73GB HDD x 4 Raid 0 時 Stripe Width 的數值就是４，而 300GB HDD x 8 Raid 0 時Stripe Width 的數值就是８

Stripe Size 在不同的廠商間又被稱為 Block Size，Chunk Size 或 Stripe Length，這個數值的大小與陣列的硬件無關，是一個可讓用戶自定的參數，Stripe Size 的大小就是陣列中每一顆硬盤存放數據時的最小單位。

以一個 73GB HDD x 4 Raid 0，Stripe Size = 128KB 的陣列為例，假設現在要把1MB (1024KB)的數據要寫入這個陣入，數據會如下分配：

１．因Stripe Width 為４，所以首先會把1024KB的數據分為４份，每份大小為1024KB /4 = 256KB，即陣列中的每顆硬盤將會被寫入256KB的數據

２．由於陣列中每顆硬盤的Stripe Size 被設定為128KB，因此256KB的數據會被分為256KB / 128KB =２ Block (單位) 後才寫入硬盤
作者: harleylg    时间: 2009-5-5 00:27
不能一概而定，看应用…
个人经验，读取为主且小文件居多（寻道敏感应用），条带约小性能越高；其它还是条带越大性能越好。
不过这好像跟硬盘、控制器也有关，最好自己不同情况都测试一下…
作者: harleylg    时间: 2009-5-5 00:35
不能一概而定，看应用…
个人经验，读取为主且小文件居多（寻道敏感应用），条带约小性能越高；其它还是条带越大性能越好。
不过这好像跟硬盘、控制器也有关，最好自己不同情况都测试一下…
作者: harleylg    时间: 2009-5-5 00:38
不能一概而定，看应用…
个人经验，读取为主且小文件居多（寻道敏感应用），条带约小性能越高；其它还是条带越大性能越好。
不过这好像跟硬盘、控制器也有关，最好自己不同情况都测试一下…
作者: bcyj    时间: 2009-5-5 02:34
Stripe Width 是由陣列(Array) 的硬件組成部份來決定，陣列的其中一個特點就是可把數據代整為零，把一個大數據細分成多份小數據同時存入硬盤中以提升整體讀寫效能，Stripe Width 的數值就相當於數據初分開的份數， ...
idolclub 发表于 2009-5-4 23:23

最后那个例子的说法少了个条件，只有在这1MB数据写入的地址是按StripeSize对齐时才是这个程况，不是的话，就会发生跨越
作者: idolclub    时间: 2009-5-9 23:29
最后那个例子的说法少了个条件，只有在这1MB数据写入的地址是按StripeSize对齐时才是这个程况，不是的话，就会发生跨越
bcyj 发表于 2009-5-5 02:34

舉這個例子只是方便說明原理，實際操作時還會產生很多不同的情況
作者: GZ_Ranger    时间: 2009-5-10 18:49
条带大小据说就是看应用。
似乎oltp型数据库肯定要小些，视频/文件服务器要大些。
小的条带似乎会提高raid5随机写的能力，据说是条带是raid卡处理的最小单位，raid5写运算时，可能需要将写入值与此条集的校验块进行运算，大多数情况下还要重写校验块，所以条带越小，单io处理的数据越小，iops可能就越大。
作者: 拳头    时间: 2009-5-10 19:55
楼上记反了，大条带提高并发，小条带提高读写，R3的条带只有512B，主要就是给视频服务器使用的。
作者: GZ_Ranger    时间: 2009-5-11 08:54
楼上记反了，大条带提高并发，小条带提高读写，R3的条带只有512B，主要就是给视频服务器使用的。
拳头 发表于 2009-5-10 19:55

r3是怎么回事我也搞不懂。
不过对于oltp数据库，确实大多数厂商都建议是8kB，无论用sql server 还是 oracle，不过在这种尺寸下，文件拷贝速度有点慢。



欢迎光临 POPPUR爱换 (https://we.poppur.com/) Powered by Discuz! X3.4