EVA Continuous Access write performance

[Graeme Wood]

Hi,

Does anyone have any figures for the CA overhead on write performance?

I have 2 x 8100's, running XCS 6200, connected using 4 x 4/256 directors and dark fibre approx 150 metres apart.

As part of the ATP/SAT procedures I have been running some performance tests using HP L&TT V4.6.

I create some 100GB vdisks and then ran the following tests, with the results as indicated. As it is dark fibre I am using synchronous mode and at present the EVA's are not doing any other work. The disk group has 40 x 450GB FC drives.

I used L&TT version 4.6...with following settings:-

2:1 compression
File size 4kb to 512kb
Tree depth 8
Tree breadth 3
24 Files per directory
Test size 9.6 GB

G:\ achieved 53 MB/s (replicated remote EVA drive)

H:\ achieved 53 MB/s (replicated local EVA drive) but if remove from DR group then achieves 67 MB/s (non-replicated)

I:\ achieved 68 MB/s (non-replicated EVA drive)

There seems to be a 20% perfomance slow down in write performance using this test.

I also used diskbash with the following command string:-

diskbash -wout -b 64k -d16 -s 100m test

When run on non-replicated disk this achieved approx 450 MB/s, but when run on a replicated disk it dropped to 95 MB/s.

Any performance feedback welcome, or even better if someone can try test on their san to see if results are similar.

p.s. I have logged a call with HP, but so far they have only been able to say that it will be slower!!!

[Víctor Cespón]

Hi, for all performance issues the right tool is evaperf. You can collect data in command mode or though the Windows performance monitor.

Monitor the replication link for bandwidth and latency. In synchronous replication the source EVA must wait until the target EVA stores the data on it's cache and sends and acknowledgement back. You must add all the times involved on this process.

Since you're using direct fiber connection over 150 meters, the latency should be small. Also, are you using 4 Gbs speed on the cable? 150 meters is the limit for multimode 50 µm fiber at 4 Gbps.

[T Downing]

CA has a set number of write and copy resources allocated to it by DR tunnel. There is one tunnel per source/destination controller pair. The resources for XCS 611 are 124 16KB write resources, 16 128KB copy resources, 64 command resources. Again each tunnel gets a set of these resources, copy if used during full copy, writes resources during normal replication. This one of the reasons you create smaller DR groups and spread them across the controller pairs, providing that will not compromise your application from being in a crash consistent stat if there is a failure.

Like vcespon said run evaperf with the drt option. They right 3 columns show these resources. My best guess is you are running out of copy resources, this is thus affecting you write performance since you are running in Synchronous mode. I don't have diskbash so I can't decipher how fast you were hitting it with 64k writes (I will assume constantly for 100 minutes), but I can see that killing the write resources.

I have seen this (copy or write resources reduced to 0 or around that) happen here it has been when a program started looping and making small continuous rights or when we were doing multiple Full Copies on groups that use the same source/destination controller pair. But these were out lying incidents and I don't see these issues on a daily basis.

If you can point me to the diskbash program I can run it here both on replicated and non replicated disk in Sync and Async just for comparison.

[Graeme Wood]

Thanks for the info around resources...I have mailed off the evaperf output to HP support to see what they suggest.

I have attached the disbash program...originally came from Microsoft to troubleshoot an I/O problem some years back.

[IBaltay]

Hi, in the lower part of this thread, there are some ideas how to approach to the evaperf counters:
http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=1239472