VMs on LUN taking more time to unzip a zip file than the VMs on NFS

[#1]

Hi,

IHAC with vmware environment on NetApp Filers (both LUNS and NFS).  Now, suddenly they observed that when they are trying to unzip a zip file it is taking more time on the vm which is store on LUN and comparitively less time from a vm stored on NFS Datastore.

We checked the IOPS and latency of the LUN they are with in range.

Any help is appreciated.

[#2]

Are the VMs on the same ESX server and have the same level of resources, cpu shares, memory?  - If so, a strange one.  NFS is said to be faster but one hell of a demonstration on this...

Bren

[#3]

Sorry are the volumes on the same aggregates of the filer?

[#4]

Hi,

Thank you very much for your response.

Yes, the volumes are part of the same aggregate.

[#5]

Is it just one ESX server?

[#6]

Hi guys,

My two cents:

I reckon it may be caused by countless reasons really - the key question is: is it a real performance-related problem (users complaining?) or just an academic observation (arguably interesting though)?

Possible explanations:

- LUNs misaligned (& NFS VMDKs aligned properly)

- LUNs fragmented

- aggregate in question has been expanded in the past - after creating LUNs, but before creating NFS datastore (LUNs / files are not automatically re-distributed across new spindles)

If the issue is worth for you further investigation - can you post the outputs of sysstat -x 1 whilst unzipping jobs are being run?

Kind regards,

Radek

[#7]

Hi,

This is on a ESX cluster (10 server).

[#8]

Hi Radek,

Thanks for the response.  Sorry for the delay in reply its being a weekend.

How can i check lun misalingment from NetApp perspective?  We are using HUK 5.2 which has only mbralign command?  We also raised this lun misaligment issue sometime back and the vmware team is saying that there is no such issue.

We did not perform any aggregate expansion..? Does volume exapnsion also creates such problems...?

Regards,

Vijay

[#9]

How can i check lun misalingment from NetApp perspective? 

You should find all the info in this TR:

http://media.netapp.com/documents/tr-3747.pdf

We also raised this lun misaligment issue sometime back and the vmware team is saying that there is no such issue.

They don't understand [NetApp] storage, that's why! Say you have an offset of 2k & do random reads 4k in size. For every read request on a LUN level, you will be doing two actual reads on the storage array from two adjacent blocks.

We did not perform any aggregate expansion..? Does volume exapnsion also creates such problems...?

Nope, I don't think so. But it can be fragmented - worth checking IMHO (LUNs tend to suffer more from fragmentation than file shares, as WAFL can't do so many clever things inside a host file system)

Regards,

Radek