Originally posted by: SystemAdmin

Hi,

i've been connecting our AIX boxes to an HDS disk array and it seems to me that i'm getting poor performance when reading data with a small block size (4k, 8k ...). Could this be because of the number of LUNs mapped on the HDS Array ports or is there any AIX device parameter adjustment that i must do? Current queue depth for instance for each disk is set to 2.
Help appreciated ...

Originally posted by: SystemAdmin

Hi,

Is it only read performance that is not good? or is write performance also affected. We run a queue depth of 16 on our HDS storage which made a significant difference.

Also have someone look at the chip utilization on the HDS array port, it could be maxed out, or getting really bad cache hit ratio's, which may mean you need to look at how you have the data placed on the ports and luns.

Also look at what your j2_maxPageReadAhead (JFS2) or maxpgahead (JFS) and try increasing, you may get some benefits.

Cheers...Steve

Originally posted by: SystemAdmin

Hi,

i've been doing tests reading data from a raw logical volume (as my databases user raw logical volumes). I've noticed that this only happens on hosts that have a lot of mapped luns (around 200 Luns). On hosts that have a few luns the read operation performance is acceptable. The host with problems has 2 Gbit FC adapters. I've seen also a parameter num_cmd_elems on the FC Adapters that has a value of 200. Should i change this value? I've seen a note saying that this should be changed acording to the Disk Array Hardware Vendor as changing it could cause data corruption. I have already tried to change the queue_depth on the disk devices without any luck. Any suggestions?

Regards...

Originally posted by: SystemAdmin

You say "it seems to me". I can't help but wonder as to the basis for this. What performance are you getting that you consider bad? By contrast what would you consider good? Where is this expectation coming from? Do you have, or have you had, some other disk setup that does satisfy you needs? Or is this based on vendor input?

I don't mean this to be critical, I'm just trying to quantify your situation.

When you say "reading small blocks" should we take that to mean that this is random reads, or sequential? Are you measuring disk performance (I/O rate, busy percent, response time) or are you looking at end user experience.

Details, please.

Jim Lane

Originally posted by: SystemAdmin

Ok. I'll give a little more detail. I'm doing sequential read using 4kb block size. Not even tried yet random read. For sequential reading 40 MB using 4kb it takes about 50 seconds on a hds disk. On a shark disk it takes about 8 seconds.
I'm measuring this data using the dd command. As our hds array is 3 years newer than shark i would assume a better response time as it has more cache, fast 15k disk, etc, etc.

Thanks,

Originally posted by: BruceSpencer

The "dd" command bypasses the filesystem. It writes directly to the device driver. So filesystem tuning is not going to help. I'd look at the adapter queue depth, and multipathing software. Are there any error log entries?

Other questions. Are any other systems hooked to the same HDS? If so, how is their preformance? How do the AIX settings differ on the server with the shark disk?

Other than that, I'd start looking more closely at the storage.

Originally posted by: SystemAdmin

Hi,

yes i have other systems connected to the hds array and in those systems the dd performance is acceptable. The only difference between the systems (they are all LPARs of the same physical system) is the number of LUNS presented to the systems. In the system that has performance problems the number of luns is 200 and in the other ones there is a much more smaller number (about 40 LUNS). The AIX settings about the adapter queue_depth (default is 2) and multipath software is the same (devices.fcp.disk.HP.xparray.mpio.rte). There are no error log entries. I'm using the round_robin algorithm as this device driver only supports round_robin or failover. I have already contacted our HW vendor and they are investigating also.
Thanks,