EVA 6x00 READ performance

[Jörg Horz]

We are using in our SAN 2 * EVA 6000 systems (112 disks) and 2 * EVA6400 systems (216 disks). All of them are running in
Continus Access mode so that each LUN is mirrored to some other storage system. All the EVAs are using a single Disk Group
to get the best WRITE performance. By settings up an ORACLE systems we face a huge number of timeouts for Database READ requests
waiting for Storage I/O. In Fact, loading a 700MB Oracle Table Space to the DB cache can take up to 90 seconds. Expecting 50Mb/sec
we should have about 14 seconds.
The DB is setup on a 100GB LUN on one of the EVA6000 Storage system, replicating to one of the EVA6400 Storage Sytems. Transactions Logs,
Dumps, etc. are stored on different LUNs.

[Adam Garsha]

Not sure what your OS is, but just a thought to get something repeatable, you could "dd" some zeros to a raw unused lun to get a feel for write throughput from OS level and then conversily read from the raw lun and send it to dev null to get a feel for what is possible for reads. You could muck around with blocksize with each approach to see if there is a sweet spot and/or a huge discrepancy from what you are seeing at the FS level and then also at the DB level.

Brainstorm'ing (all could be worthless thoughts):

What is FS? is it config'd weirdly? Was data copied over strangly and driving a huge amount of fragmentation? Does HP have an alignment recommendation for the FS in question? Or are you using Oracles volume management? Doing any software raid ontop of the EVA's LUNs? How big is your database bufferspace? suitable or shrimpy?

[Mikko Niskanen_1]

Aye,

A few docus that might help:

Using the ms_scan_time option to display mass storage device scan times:
http://bizsupport1.austin.hp.com/bc/docs/support/SupportManual/c01914718/c01914718.pdf

EVA 6400 Performance White Paper:
http://h20195.www2.hp.com/v2/GetPDF.aspx/4AA2-9570ENW.pdf