EVA 4400 - need help with performance issues in VMware

[Alzhy]

Not to sound like a broken record:

"I say again -- the EVA is BAD for co-hosting heavy hitters with non-heavy hitters.. Your will ALWAYS have issues if you do not isolate one or the other."

Or split up your big Vdisk into smaller ones so you can spread the load between the 2 controllers.


BUT best solution -- get a NetApp or HP's new acqu - 3PAR array for your Virtual Ecosystem.

[sam bell]

Spreading the load over two controllers won't let me see any performance improvements since the disks are the bottleneck and not the controllers.

I know that having a dedicated disk group for VMware would be the best solution and I will focus on that.

[Alzhy]

Well good luck sir...

Let us know how it goes.

[Azadeh]

Hi SAM

There is a question!!
how many SAN switch do you have ?
Each EVA4400 has 4 ports ( 2 port in each controller )
If you connect all 4 ports of EVA4400 to the SAN switch then you have at least 8 path to each LUN!!

[Uwe Zessin]

This is an I/O scheduling problem, not a bandwidth problem.
No amount of paths will help.

[Alzhy]

I just remember one tweak that we've done out of a very I/O hogging EVA connected server.... You can try reducing Queue depth on the DWH server that seems to be hogging I/O if that helps (without ipacting performance of course)... I don;t know what the default setting is for WIndows 2K8 bnut you may try looking at reducing it... If its default is say 32 -- try lowering it to 16 or even down to 8...

[sam bell]

I already thought of this as a quick and dirty workaround. However, lowering the queue depth will definitely result in a lower performance for the DWH system, doesn't it? I mean, if fewer I/Os can be transmitted to the EVA this MUST result in a lower performence, right?

But again, I am not an expert in terms of storage performance and I am still not really sure about the influence of the queue depth.

[Alzhy]

It will be a hit and miss thing... Whjat we've done is to bring it down gradually...

It was a Linux system though but very HOT DB.. Default was 32. We brought it down to 16, then 8 then finally to 4.....

[sam bell]

So basically you have throttled the Linux DB system by reducing the queue depth in order to reduce this system's impact to the EVA?

[Alzhy]

That is correct.
Worked beautifully in that on very Heavy DB server activity - it no longer was HOGGING I/O on the EVA...

In your case - it wil be YMMV though so be cautious and mindful...