On Wed, Feb 1, 2012 at 8:19 AM, Xianghua Xiao <xiaoxianghua@...> wrote:
> I agree, maybe the cpu/mem is overloaded under RAID5(I use 4 disks),
> will do more debugging.
Well, if you only use 4 disks for RAID5 and four disks for RAID0 that
is not a fair comparison, because, quite apart from the parity issues,
four disks striped should give you better performance that RAID5 on
four disks because only three of them are being used for data.
That being the case, I am suspicious of your read numbers for local RAID5.
What size copies are you doing? Also, did you have a file system on
the volume or were you exporting the volume directly?
> Thanks!
>
> On Tue, Jan 31, 2012 at 11:22 PM, Richard Sharpe
> <realrichardsharpe@...> wrote:
>> On Tue, Jan 31, 2012 at 8:56 PM, Xianghua Xiao <xiaoxianghua@...> wrote:
>>> I switch from blockio to fileio and enabled NV_CACHE and it helped:
>>> local RAID0 R/W : 400MB/400MB, iscsi: 340MB/192MB
>>> local RAID5 R/W: 400MB/240MB, iscsi: 315MB/124MB.
>>
>> Are these both software RAID? I looks like you are, since the local
>> RAID5 READ is the same as the RAID0 READ (seems like you are using 5
>> drives in the RAID5 case). If you are using 4 drives in the RAID0 case
>> then you are at about the limit of the drives.
>>
>> These numbers look only a little strange. If you are getting 400MB/s
>> read for both local RAID0 and local RAID5, why is the RAID5 READ
>> lower? I would expect that the RAID5 READ case is the same as the
>> RAID0 READ case, unless you have some bad sectors on a drive.
>>
>> How much CPU do you have left when doing the RAID5 write locally? It
>> could be that you do not have enough CPU or memory bandwidth to both
>> do the RAID5 XOR and iSCSI at the same time.
>>
>>> This is way better than original values, I'm using crystaldiskmark to
>>> do the test.
>>> HANDLER vdisk_fileio {
>>> DEVICE disk01 {
>>> filename /dev/md0
>>> nv_cache 1
>>> }
>>>
>>> DEVICE disk02 {
>>> filename /dev/md1
>>> nv_cache 1
>>> }
>>>
>>> DEVICE disk03 {
>>> filename /dev/md2
>>> }
>>> }
>>>
>>> TARGET_DRIVER iscsi {
>>> enabled 1
>>>
>>> TARGET iqn.2012-01.test.com:storage.disk01 {
>>> enabled 1
>>> rel_tgt_id 1
>>>
>>> LUN 0 disk01
>>> }
>>>
>>> TARGET iqn.2012-01.test.com:storage.disk02 {
>>> enabled 1
>>> rel_tgt_id 2
>>>
>>> LUN 0 disk02
>>> }
>>>
>>> TARGET iqn.2012-01.test.com:storage.disk03 {
>>> enabled 1
>>> rel_tgt_id 3
>>>
>>> LUN 0 disk03
>>> }
>>> }
>>>
>>> On Tue, Jan 31, 2012 at 1:55 PM, Xianghua Xiao <xiaoxianghua@...> wrote:
>>>> will do this when I get access to that box later.
>>>> meanwhile I am also looking in ways on how to tune those iscsi-related params.
>>>>
>>>> thanks!
>>>>
>>>> On Tue, Jan 31, 2012 at 1:34 PM, Bart Van Assche <bvanassche@...> wrote:
>>>>> On Tue, Jan 31, 2012 at 6:59 PM, Xianghua Xiao <xiaoxianghua@...>
>>>>> wrote:
>>>>>>
>>>>>> yes I applied that patch.
>>>>>
>>>>>
>>>>> Posting scst.conf would help - settings like e.g. nv_cache can cause a huge
>>>>> performance difference.
>>>>>
>>>>> Bart.
>>>
>>> ------------------------------------------------------------------------------
>>> Keep Your Developer Skills Current with LearnDevNow!
>>> The most comprehensive online learning library for Microsoft developers
>>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
>>> Metro Style Apps, more. Free future releases when you subscribe now!
>>> http://p.sf.net/sfu/learndevnow-d2d
>>> _______________________________________________
>>> Scst-devel mailing list
>>> https://lists.sourceforge.net/lists/listinfo/scst-devel
>>
>>
>>
>> --
>> Regards,
>> Richard Sharpe
--
Regards,
Richard Sharpe
|