What PE size to use when creating VG

[NDO]

Hi all

I have a server that receives files and processes them not bigger that 8Mb and not smaller that 100kb. Initially the VG´s were created with a PE size of 64Mb. In recent days we are having issues with %wio being big, and %idle close to 0 and avwait bigger that avserv. We suspect the system is I/O bound. The support guy came over and one of his suggestion was that we should create a VG with the smaller PE size.

Can this be a problem?

FR

[Bill Hassell]

PE size has no effect on I/O. It is a bookkeeping value used in LVM to locate each extent.  64MB is mandatory for terabyte LUNs as the maximum number of extents is 65535.  To change the extent size requires destroying the current VG and building a new one and restoring the data. But even if you can create the VG with smaller extents, the I/O will not be affected. The only area where I/O might be affected is for JBOD disks that use extent-based stripes. Larger extents means that sequential or adjacent data is more likely to reside in one location. For modern SAN disk arrays, all of this is handled in the array.

[NDO]

Hi

thanks for the reply. Actually the system uses a NetApp as its storage, and the I/O issue resides on LUNs of 75Gb and 235Gb. Your comments them can suggest me that we might have a problem with the application, in fact if the app is stopped, the 100% busy disks are going back to normal, no avwait is bigger than avserv. At the moment the patch level (QPK and Hwenable) are of 2009. Perhaps we should install 2010 or 2011 patchs.

FR

[leewilliam99]

It is always preferable to keep up to date on patches, no more than a year behind. But 100% disk usage in sar is very misleading. NetApp is not known as a high performance array, but more of an economy array. If you have done all the normal OS things like multi-path load balancing and making sure the queue depth is large enough,nothing will make a slow array push data any faster. Note that the application is why the server exists -- and in fact, 100% I/O is probably desirable because you are getting your money's worth. But if the application is doing dumb things like small Kbyte I/O when application caching could reduce the I/O count with larger (Mbyte) records, then yes, the application is not working efficiently.

Unfortunately, sysaadmins are asked to fix performance issues by adjusting the imaginary go-faster parameter since we don't have access or control over the databse. When all you have is a hammer, every problem starts looking like a nail.

[NDO]

Thanks a lot for your inputs, I may have  missed the queue depth parameter, should I increase it? Where should I view what value is set for it?

And yes the average size of the files coming in are very small from kbs to not bigger than 4Mb.

The users are saying that application (mediation) sometimes  is slow, perhaps when %idle is close to 0 (zero).