Storage Boards Cleanup
To make it easier to find information about HPE Storage products and solutions, we are doing spring cleaning. This includes consolidation of some older boards, and a simpler structure that more accurately reflects how people use HPE Storage.
Disk Arrays
cancel
Showing results for 
Search instead for 
Did you mean: 

EVA4000 RHEL 5.2 poor I/O performance

achandra
Occasional Visitor

EVA4000 RHEL 5.2 poor I/O performance

Hello,

Using EVA4000, RHEL 5.2, latest emulex driver for lpe1500, and multipath.conf with round-robin setup.

I have 8 seperate luns presented to me and ALL are setup as raw devices.

When running a single threaded read or write the I/O performance is pretty bad --at 30MB/S. In a multithreaded read or write performance increases to about 100MB/S (assuming i aggregate the 20MB/S-30MB/S across 5 disks).

Here is the issue I see I/O literally throttle on the box, rise then drop.

This is the same type of issue encountered in these posts as well -

http://fixunix.com/hewlett-packard/101792-q-eva-4000-performance.html


http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=1148105

http://newsgroups.derkeiler.com/Archive/Comp/comp.sys.hp.hardware/2007-08/msg00075.html

AND VERY CLOSE to this -

http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=1166182


SO...whats the magic fix here? As it seems every single one of the above threads doesnt have a conclusive "this worked".






5 REPLIES
IBaltay
Honored Contributor

Re: EVA4000 RHEL 5.2 poor I/O performance

Hi,
there are several parameters to be checked/ tuned, e.g.:
a) the more disks in the DG the more performance -> this is the most difficult,
because you need to buy some more physical disks :-)...
b) multipathing set to always hit the master controller (and minimize IOs to the slave controller - this can be measured by evaperf utility on the Command view server - if the mirror port si heavily used, then the multipathing setting should be tuned as follows:
b1) if you have MPIO like multipathing with ALB, the VDISK presentations should be set to the SET PREFFERED PATH=NONE on the EVA side
b2) if you have PVlinks like multipathing (manual mapping) the the VDISK presentations should be set to the SET PREFFERED PATH=CONTROLLER A or B on the EVA side.
And on the host side the primary paths should be inline with this. Also half of the primary paths should be set to the first and half to the second fabric

c) the queue depth/queue length (throttle) could be increased from their defaults to the values of 64 or 128


the pain is one part of the reality
achandra
Occasional Visitor

Re: EVA4000 RHEL 5.2 poor I/O performance

With respect to b1 and b2 all I have done is to make sure my multipath.conf looks like this -
device
{
vendor "(COMPAQ|HP)"
product "HSV1[01]1|HSV2[01]0|HSV300"
getuid_callout "/sbin/scsi_id -g -u -s /block/%n"
prio_callout "/sbin/mpath_prio_alua /dev/%n"
features "0"
hardware_handler "0"
path_selector "round-robin 0"
path_grouping_policy group_by_prio
failback immediate
rr_weight uniform
no_path_retry 12
rr_min_io 100
path_checker tur
}


And Im simply using raw devices, where dev/raw/raw1 points to a multipath device and so on to the next device.


HOW DO I SET THE DEPTH/QUEUE LENGTH BELOW??

Is that the lpfc options in modprobe.conf?

c) the queue depth/queue length (throttle) could be increased from their defaults to the values of 64 or 128
IBaltay
Honored Contributor

Re: EVA4000 RHEL 5.2 poor I/O performance

yes,
/etc/modprobe.conf.local file:
lpfc options lpfc_lun_queue_depth=64 or 128
(maybe it needs the reboot :-((( ).
But check the performance after each change..
the pain is one part of the reality
achandra
Occasional Visitor

Re: EVA4000 RHEL 5.2 poor I/O performance

Also with respect to the posted multipath.conf settings, is that the ALB you are referring to? and does my setup refer to b1 or b2? (Need to make sure we are in line here).
IBaltay
Honored Contributor

Re: EVA4000 RHEL 5.2 poor I/O performance

see this ALB/mpath_prio discussion:
http://www.redhat.com/archives/dm-devel/2007-August/msg00090.html

here is also the Linux device mapper support document:
http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?lang=en&cc=us&objectID=c01475612&jumpid=reg_R1002_USEN
the pain is one part of the reality