November 22, 2013 at 9:16 am
Hello - a common situation is to have a vendor come in to set up their software and gives the memory & cpu specs to the VM admin.
For example, the vendor wants 16GB of memory, the VM admin says they can use 2 GB. It becomes a debate. How can you tell who is right?
Is there a way to show how much resources a database actually needs?
Please don't respond with a business related point of view - I want to gather concrete technical facts.
Thanks
Dave
November 22, 2013 at 9:20 am
the size of the vendor database is one of the things i'd like to know up front;
that's a decent initial indicator for me.
if the entire database is say, 500 meg, then even if the whole thing was loaded into SQL server memory, 2 gig would be plenty.
Lowell
November 22, 2013 at 12:21 pm
An ideal situation is where you have the same amount of RAM as the data file size for the database + 2GB for the operating system/etc.
However, that is not really necessary, but I would not have less than 4GB of RAM to start with, then watch your disk queue length/cache hit ration and add RAM until the cache hit ratio stays over 98% most of the time. Disk queue length should stay in the low single digits.
There are a lot of factors to consider though.. for instance, if you have an OLTP database that has a lot of data changes and a lot of reporting, then you'll want not only extra ram, but TEMPDB and transaction logs on a high speed disk, such as an SSD to avoid lock waits. If you have a database that is 90% only collecting data or 90% only reporting (little or no data changes), then you can get away with less RAM.
Also, if your total database size is less than 40GB, then 4GB of RAM generally is sufficient, in my experience.
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply