Can anyone point me in the direction of a whitepaper or similar that talks about Datastore performance?
I need some guidance on how to configure my datastores. For example I have a 512GB datastore which only has 25Gb free (did I say only?!). Does the performance degrade as I fill it up (eg: like normal disk) or is that irrelavent?
Thanks
Andrew
Message was edited by: Andrew : trypo's
AndyShine
That would be correct if he meant contention, the question was not worded that clearly, to me his question sounded more like simple disk space question rather then a contention question though. A VMFS volume filling up is not really going to cause performance problems, more VM's on a single volume will usually cause increased contention for resources. VMFS volumes can fill up in other ways besides adding more VM's to them.
No it will not really degrade, maybe slightly but not enough to effect server performance.
Defragging virtual disks - http://www.vmware.com/community/thread.jspa?threadID=77661&tstart=0
Was this post about defragmentation or about contention as more vm's are fighting for resources?
In my humble opinion, yes, as you fill up that server with vm's that use that storage, yes, there will be delay as each vm uses its allocation of hard drive space. No way around that!
Respectfully,
Matthew
That would be correct if he meant contention, the question was not worded that clearly, to me his question sounded more like simple disk space question rather then a contention question though. A VMFS volume filling up is not really going to cause performance problems, more VM's on a single volume will usually cause increased contention for resources. VMFS volumes can fill up in other ways besides adding more VM's to them.
Agreed. Team work works!
Respectfully,
Matthew
Definitely, I find that a compilation of replies to a question are much more beneficial then a single users response. Everyone has different experiences, knowledge and viewpoints. Each reply to a post usually adds more value to it and in turn is more helpful to the thread creator and anyone else who reads it.
If you are interested in reading more on storage Andrew here's some links...
Larger LUNS = More Disks = More Performance - http://www.vmware.com/community/thread.jspa?threadID=84843&tstart=0
Choosing and Architecting Storage for your Environment - http://download3.vmware.com/vmworld/2006/adc0135.pdf
VM Disk Scenarios and Performance - http://www.vmware.com/community/thread.jspa?messageID=661499
Unofficial storage performance thread - http://www.vmware.com/community/thread.jspa?messageID=584154򎧚
SAN Configuration Guide - http://www.vmware.com/pdf/vi3_esx_san_cfg.pdf
SAN Conceptual and Design Basics - http://www.vmware.com/pdf/esx_san_cfg_technote.pdf
SAN System Design and Deployment Guide - http://www.vmware.com/pdf/vi3_san_design_deploy.pdf
LUNS - http://www.vmware.com/community/thread.jspa?messageID=333672񑝨
LUNS Size - http://www.vmware.com/community/thread.jspa?threadID=36725&start=0&tstart=0
Sizing LUN for enough free space after VM - http://www.vmware.com/community/thread.jspa?messageID=649338
Smaller LUNS or Larger LUNS - http://www.vmware.com/community/thread.jspa?threadID=90203
Thanks for all your replies.
Yes, my question was a bit vague, blame that on my ignorance\lack of familiarity of some of the undelying concepts. I suppose time and experience will over come that . I was actually looking at the narrow issue of the performance of a (nearly) full datastore, I hadn't even thought about contention and defragmentation.(The link to the discussion on defragging is good advice)
I can see I'll be putting myself to sleep at night reading through all the links that have been provided
Regards
Andrew (the esx newbie)
Message was edited by:
AndyShine
Message was edited by:
AndyShine
You will hit issues with redo logs and committing them if the disk is obviously nearly full so beware when using them and not removing them.
Paging needs space on the LUN so I always like to keep 50GB free.
VMFS isnt going to need defragging it will be the VM's themselves as it is a flat file system designed for big VMDK's.
Dan