Performance problem on EVA and Windows striped volume

[Morten Nielsen_4]

The customer requires a mount point of 6TB - max lun size on the EVA is 2TB - so 3x2TB luns are created, presented and striped together on the host.

Problem:
Write performance for the volume is +100 MB/s - read performance for the volume is max 40 MB/s.

http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?objectID=PSD_OI040301_CW02&prodTypeId=12169&prodSeriesId=377751&locale=en_US

Have done this, but not compatible for dynamic disks as is required here - so what do I do??

BR
Morten Nielsen

[Duncan Edmonstone]

Morten,

Whay did you stripe the LUNs? As the EVA is already striping across all the disks in the disk group, it doesn't gain you anything... in fact it might be confusing the caching algorithms (particularly for sequential reads/writes).

I'd try this agin with just spanned volumes rather than striped volumes and see how you get on.

HTH

Duncan

[Morten Nielsen_4]

Hi
Tnx for the reply.
Being a MASE I am fully aware of how the EVA functions.
Spanning is also an option but decreases the performance potential in windows for offloading transactions as you are only accessing one lun except when a lun runs full (HBA-drivers are storport = queueing is done seperately for each device = more devices = better chance for windows to offload a transaction to the HBA when there are more devices/buffers active in parallel) - remember that it does not makes sense that you can write faster than you can read, normally it would be the reverse that is the problem.

I already tested to eliminate lun caching on the EVA to see if this was stressing the cache too much, evaperf did not report this in advance and it also made no difference for the read/write throughput afterwards.

BR
Morten

[Adam Garsha]

This may sound like a dumb response, but if you are able to "try stuff": I would de-present to the windows box and present the very same LUNs to a Linux box or HP-UX box or Tru64 box if one is handy and already on the SAN and not in production. Run your same/similar I/O test on UNIX after putting the luns in a volume group or disk group or domain or whatever; see what you get out-of-the-box. This would help you to point to the OS/Windows.

Is this random I/O or sequential I/O?

Are there directories with many many files on a single Volume? or DB-style with a few Big files on the Volume?

How many HBA's are we funneling through?

Is this an EVA with active/active or active/passive controllers?

How does performance look when you just use one 2TB LUN (only a portion of the data) for the test?

Maybe look at:
1.) how many paths am I using and am I load balancing I/O across those paths?
2.) Is there a tweak needed on windows when big directories with many many files?
3.) Do you need to modify the queue depth on the HBA's to properly support your many thread random I/O on this huge Volumes?

Anyway, maybe above will shake-something-loose.

[Adam Garsha]

One other thing to consider is virus checker settings.

[Morten Nielsen_4]

Testing against another OS seems a moot point as the customers application has to run on windows.

All transfer being done is large sequential I/O (to simulate the customers backup application (mentioned above) - have tested with robocopy and IOmeter), the EVA is an 8K with 56 pcs 500GB FATA in one diskgroup for mainly this purpose, also another diskgroup with 42 pcs 146GB FC, no other significant traffic at all to the EVA while testing.

HBA's are 2 pcs FCA2214 DC - one path from each adapter is reserved for disk-access (= 8 total access paths to the EVA) - the remaining HBA ports are reserved for traffic to tape (ESL712). Both adapters are on different PCI-busses of same speed in a quad-cpu DL585 with 4GB RAM.

When accessing only one lun (regardless of creating it as basic, GPT or dynamic) then read performance is fine - did some checking using diskpar - seems that windows will allways reset the partition alignment back to offset 63 regardless of how you initially align the basic partition you create first, this means that a lot of individual ntfs-blocks (when striping over multiple of disks like this) will be mis-aligned to the partition boundaries, so if creating to volume as a spanned volume less blocks are misaligned and also results in better performance than stripe.

I have have re-created this issue on another server so it seems to be a general issue with EVA-luns for windows.

Anyone from HP that would like to comment?Will keep the thread open for couple of days.

BR
Morten Nielsen

[Morten Nielsen_4]

not fixed - looks like M$ problem