P2000 slow performance

[Charles McCary]

Group, I have an rx6600 direct attached to a P2000 disk array. I've created a Raid5 LUN and presented it to the host.

I created an lvol on this LUN, then created a filesystem with the following options:

mkfs -F vxfs -o bsize=8192 -o largefiles /dev/vg_bill_data/rlvdata

Mounted the filesystem with these options:

/dev/vg_bill_data/lvdata /MIBAS_BILL_DATABASE/data vxfs delaylog,mincache=direct,convosync=direct 0 2


When I run a test dd command, I'm only seeing 26MB per second.

alxapor30xs:root:/MIBAS_BILL_DATABASE/data/test# time sh -c "dd if=/dev/zero of=ddfile bs=8k count=2000000 && sync"
2000000+0 records in
2000000+0 records out

real 10:16.0
user 1.4
sys 43.5



Any ideas or thoughts on what I can check?

[SunnyS]

Charles,

DD is not a good tool to measure performance. Main problem with it is that it issues 1 I/O at a time and waits for it to complete before issuing another I/O. Both the P2000 and the HBA (not sure which one you have) can easily issue/handle many more I/Os than that. That is why you are seeing low numbers.

If you are on 11.31, you also have the option to change the queue depth on a per LUN basis. By default it is set to 8. Just do an online search on max_q_depth. Note, with DD queue depth is not relevant (as DD is issuing only 1 I/O at a time), but with a real benchmarking tool, queue depth will also come into play.

[TTr]

You used a very small block size and the dd had way too much overhead. Use much larger block sizes such as 1024k.

You may want to try concurrent dd jobs as well.

[Bill Hassell]

> dd if=/dev/zero of=ddfile bs=8k count=2000000

bs=8k is a very small record size. A small record size means high system overhead. Try this:

dd if=/dev/zero of=ddfile bs=2048k count=7800

[Charles McCary]

OK - I feel better. Ran some dd's with bigger block size (THANKS BILL) and here's the results:

with 9 concurrent dd writes:

395570586 per second.

with 7 concurrent dd reads:
407779555 per second.


I still have a concern. What started all of this is that we're trying to run an frecover to move some data from an older server to this one and the frecover takes much longer on this server. If no one has any ideas, I will probably open a new thread for that, since I'm ok with these numbers.

[Charles McCary]

Interesting....tried these on a different LUN (RAID 10) and got SLOWER response.

Here's how the filesystem was created for this RAID10 lun:

mkfs -F vxfs -o bsize=1024 -o largefiles /dev/vg_bill_log/rlvdblog

here's how it's mounted:
/dev/vg_bill_log/lvdblog /MIBAS_BILL_DATABASE/dblogs vxfs delaylog,mincache=direct,convosync=direct 0 2

here's the write times:
I'm only seeing about 200Mbps on this lun for concurrent dd writes

I'm only seeing 180mbps on this lun for concurrent dd reads

Both luns are created and presented from the direct attached P2000