Striping performance

[Xavier MIGNOT]

I need some help on striping.
question 1:
I have 2 disk channels (c0/c1); is it better to strip only on one disk on each channel or on multiple disk on each channel (same disk with same I/O speed)
question 2:
if yes answered to question 1, is the order of the disks in vg important ? I actually use the followinfg order : c0t11,c0t15,c1t11,c1t15. I suppose that performance will increase when order in LE is set to c0t11,c1t15,c0t15,c1t11
question 3:
about strip size on HFS, is 8k the best value (I actually use Progress database with 1k blocksize)
Thanks. have a nice day.

[Stefan Farrelly · Accepted solution]

The largest performance benefit for striping is channels (controllers). Striping across multiple disks on the same controller still helps, but only a small-medium amount - nowhere near as much as using multiple channels (large increase).

you can test it yourself. Create your lvol striped in different ways then test with;

time dd if=/dev/vgxx/rlovlyy of=/dev/null bs=1024k count=50

And see which is fastest.

[Robert Thorneycroft]

Question 1.
You should definitely use two disks per channel as you will double the number of drives and therefore on average half the queue length per disk.

The reason to increase the number of channels available is to prevent a bottleneck at that point in the operation but I would be extremely surprised if two disks would be enough to saturate a single channel (Unless you are running some very old SCSI).

Question 2.
I would set the disks up so that they go Disk1 Ctl1,Disk2 Ctl2, Disk3 Ctl1, Disk4 Ctl2 as you mentioned, the reason for this is fairly obvious in that you will be preventing large quantities of data going down one channel whilst the other is idle.

Question 3.
You milage may vary on this one, I once had to deal with a company whos product basically sucked. In trying to prove that it was the system I was forced to reconfigure a 1/2 Terabyte database with blocksizes ranging from 4k to 8M, to be quite honest I could not really notice any difference, and having spent every weekend for months at work doing this I gave up at this point.
You best bet would probably be to set a very small value and test performance with your database and then a very large and repeat the test, if you do notice your performance is significantly better at one end of the spectrum you can play around with values around there. Unfortunately I/O tuning on a database is not really a one answer fits all afair.

I hope this helps a bit.

Kind regards,

Robert Thorneycroft