POPPUR爱换

标题: 無聊使用Driver-based RAID作一些不同Stripe Size的測試.. [打印本页]

作者: per1-q1222 时间: 2010-12-19 20:55
标题: 無聊使用Driver-based RAID作一些不同Stripe Size的測試..
本帖最后由 per1-q1222 于 2010-12-19 21:00 编辑

我相信這類測試已有相關文章可循...
不過這次我要用ioMeter來一些比較特別的測試...
Driver-based RAID又稱Firmware-based RAID, 也有人叫fake RAID....
我們可以看下面這張圖, 這張圖是來自Adaptec by PMC的一份文件-Adaptec Hardware RAID vs Software RAID所示:

從這張Stack圖可以發現其中Host RAID Engine指的就是RAID的相關算法...
可以理解到Host RAID Engine是被封裝在Driver裡面...
RAID的操作是當進入作業系統載入完後才進行操作...
他的優勢是..
這樣的設計不會侷限在哪種IOC下...
只要透過firmware載入相關的Option ROM用來設定有關RAID的組態和定址到某個IOC的位址...
開機進行初始化的時候會載入一個Pre-Boot選單, 用來預先設定有關RAID的組態...
真正操作是在進入OS後才進行...
較低的成本是他的優勢...
不需要額外的硬線設計成本, 例如像是Hardwate XOR Assist設計或著built-in processor實作....
當然這是要付出代價的..
1. 不當H/W reset, 可能導致寫入條帶不全, 毀掉VD, H/W RAID建立在自有的RAID stack, 不當H/W reset還是會繼續運行....
2. RAID Engine是建立在Driver裡, 可能會受到非法的例外操作導致對資料安全性造成衝擊
3. 某些RAID模式下, 會提供很低的寫入性能, 例如RAID5.
4. 有限的功能限制
5. 沒有built-in processor, 全部的相關RAID運算都要交給Host CPU操作...
大致上就是這幾點缺陷...
這次透過ioMeter測試上有主要幾點:
1. 不同Stripe Size的傳輸速度為何...
2. 不同Stripe Size對於I/O request觸發的中斷數量為何
3. 不同Stripe Size對於CPU所獲得的效益為何..
==使用環境==
IO Controller: Intel ICH10R Controller
Option ROM Version: 8.9.1.1002
Storage: Crucial C300 128GB x2 (RAID 0; 回寫快取我是強制關閉...)
CPU: Intel Xeon W3570@3.2GHz
==ioMeter規格設定==
Queue Depth強制設成256佇列...

這個規格方案是最大I/O讀取操作...
來看看測試結果, 小弟將它弄成一張表單:

各類折線圖情況:
這個很容易明白, 不詳述...

超小的stripe size事實上是很爛的設定,這I/O中斷數量實在嚇死人..

這是一個interrupt所需要的時間, 不表意見...

CPU所獲取的I/O效益在64K尺寸左右下可以看到最高點...

下面這張, 不同Stripe Size, %DPC Time, CPU使用量的一整張列表, 看不懂得可以忽略..=3=:

DPC queue被卡在某顆CPU上...
這個問題和OS與硬體設計有關....
大量的中斷操作可能發生對於多核心系統無法分配....
大致上就這樣..
謝謝惠顧...!!
各位自行參考看看要使用怎樣大小的Stripe Size..

作者: alen 时间: 2010-12-19 21:03
thx 4 share，看来还是设置成64 or 128K为好。

作者: wlx101 时间: 2010-12-19 21:05
谢谢LZ, 学习了.

作者: sailofcloud 时间: 2010-12-19 21:22
本帖最后由 sailofcloud 于 2010-12-19 21:26 编辑

您这两块C300可真没被少折腾啊。
4k read和128k read在sata传输层所消耗的资源是不同的
简单的对比速度不能直观的反应出差别。

还有就是4k stripe怎么4k对齐？测试出的瓶颈是在sata传输层。不是控制器，也不是SSD
//ich10R就是所谓的driver based raid？
//option rom去哪儿更新？

作者: per1-q1222 时间: 2010-12-19 21:30

sailofcloud 发表于 2010-12-19 21:22
您这两块C300可真没被少折腾啊。
4k read和128k read在sata传输层所消耗的资源是不同的
简单的对比速度不 ...

Option ROM用MMTool可以強制替換..
但是風險要自擔...
ICH10R是Firmware/Driver-based RAID..

"还有就是4k stripe怎么4k对齐？测试出的瓶颈是在sata传输层。不是控制器，也不是SSD"...
聽不太懂請賜較?..

這篇部不是想表明性能上的問題...

作者: sailofcloud 时间: 2010-12-19 22:01
本帖最后由 sailofcloud 于 2010-12-20 19:36 编辑

回复 per1-q1222 的帖子

赐教不敢。
连蒙带猜略知一二，猜错之处请轻微拍砖。

stripe 为4k时。每次读取单块SSD的大小为2k，这时SSD的读取没有做到4k对齐。读取效率降低到4k对齐的一半。不过由于读取速度足够快，而sata传输又比较慢，所以测试4k stripe和8k stripe时，测试结果一样。

8k stripe性能低于16k stripe
对单块SSD就是4k读取和8k读取。
sata在完成一条4k读取的命令和一条8k读取的命令效率是不同的。
4k读取，发读命令，建立连接(ncq)，传输数据4k，命令完成
8k读取，发读命令，建立连接(ncq)，传输数据8k，命令完成
64k读取，发读命令，建立连接(ncq)，(传输数据8k) x8，命令完成

发读命令，建立连接，命令完成，对于一条ncq读取命令，这三点消耗的资源是固定的。
所以，一条读取命令的数据量越大，则效率越高。
CDM测试C300的读取， 512k为260MBps，4k为210MBps，这个差距有一部分原因就是sata读命令传输效率引起的。

您的测试中，stripe size提高使读取速度提高，我感觉很大一部分来自于读取命令效率的提高。

作者: aliguagua 时间: 2010-12-19 22:27
做个记号，明天再仔细研究大侠的文章

作者: per1-q1222 时间: 2010-12-20 01:16

sailofcloud 发表于 2010-12-19 22:01
回复 per1-q1222 的帖子

赐教不敢。

"stripe 为4k时。每次读取单块SSD的大小为2k，这时SSD的读取没有做到4k对齐。读取效率降低到4k对齐的一半。不过由于读取速度足够快，而sata传输又比较慢，所以测试4k stripe和8k stripe时，测试结果一样。"
沒有這麼誇張...
Seq. Test影響性不大

"您的测试中，stripe size提高使读取速度提高，我感觉很大一部分来自于读取命令效率的提高。"...
我覺得不要想太多..
這是ioMeter設定上的問題...

我想應該拿傳統HDD測試會比較單純...
這邊主要想了解的是Driver-based RAID對於Host-CPU所帶來的影響性...
SSD那邊是不用管了...

作者: sailofcloud 时间: 2010-12-20 19:49
回复 per1-q1222 的帖子

哦
64k stripe cpu效率最高
dpc啥意思？

作者: per1-q1222 时间: 2010-12-20 20:04
本帖最后由 per1-q1222 于 2010-12-20 20:05 编辑

sailofcloud 发表于 2010-12-20 19:49
回复 per1-q1222 的帖子

哦

這個測試不要理了..
還有些問題要釐清
DPC是和中斷有關的東西...

http://www.ithov.com/Article/Windows7/Win7Skills/93264_6.shtml
晚點會上一些詳細的..
包括跟Hardware RAID比較...

作者: per1-q1222 时间: 2010-12-20 20:06
本帖最后由 per1-q1222 于 2010-12-20 20:07 编辑

我在進IMR模式的LSISAS2008(ROMB)進行檢測的時候發現很鳥的問題..
MSI-X根本沒效果...

作者: per1-q1222 时间: 2010-12-20 23:07
本帖最后由 per1-q1222 于 2010-12-20 23:08 编辑

編表編好了..
LSISAS2108, LSISAS2008, ICH10R...
可以比較其差異...
由於表有點大..
數據上要製圖需要花很多時間..
所以暫不做這方面..
CPU Effectiveness是有其計算式...
CPU Effectiveness=IOPS/CPU使用量...
這不一定是唯一的衡量標準...

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