September 21, 2009 at 8:01 am
We are using SQL Server 2005 on Windows 2003 servers. i have noticed that since many days my SQL Server memory usage is been increasing to upto 65%. and i know that SQL Server is using all those memory. Does anybody have any idea from where do i start to investigate and how to resolve this? Step by step details is needed since i am a newbie. or anythig you all have is ok.
Thanks
September 21, 2009 at 8:10 am
Other than the above are you experiencing any other problems?
September 21, 2009 at 8:12 am
No other problems. Its SQL Server who is consuming all those memory, because after hours my CPU usage is almost 1-2%. But increases in day time.
September 21, 2009 at 8:25 am
Based on this, I don't think you have a problem.
Couple of questions however. What version of SQL Server 2005 are you running (including CPU type, x32 or x64), how much memory does the server have, and how much memory is SQL Server configured to use (min and max).
September 21, 2009 at 8:34 am
I have :-
SQL Version :- 9.00.3239.00 (MS SQL Server Enterprise Edition (64 bit)
CPU type:- x64
Memory :- 32763 MB
Minimum server memory (in MB) :- 0
Maximum server memory (in MB) :- 31000
September 21, 2009 at 8:46 am
Based on this info, I really don't think you have a problem. SQL Server will use as much memory as it needs to do its job constrained by the max memory allowed.
September 21, 2009 at 8:53 am
It will release memory to the OS if there is pressure, albeit slowly.
If you want SQL to use less, set a max limit that's lower. Otherwise, ignore it. SQL is designed to continue to grab memory as it can. Even if it's not busy, it will store data in memory as a cache, in anticipation of using it again.
September 21, 2009 at 8:58 am
Isnt it a Rule of Thumb that you leave 10% of the total Memory to the OS and the rest for SQL Server?
-Roy
September 21, 2009 at 9:01 am
Roy Ernest (9/21/2009)
Isnt it a Rule of Thumb that you leave 10% of the total Memory to the OS and the rest for SQL Server?
Not really, it used to be 75% given to SQL. normally you would leave minimum of about 2-3 GB to the OS, depending on if it was a dedicated sql box or not.
that was also dependent on the SQL Version.
--------------------------------------------------------------------------------------
[highlight]Recommended Articles on How to help us help you and[/highlight]
[highlight]solve commonly asked questions[/highlight]
Forum Etiquette: How to post data/code on a forum to get the best help by Jeff Moden[/url]
Managing Transaction Logs by Gail Shaw[/url]
How to post Performance problems by Gail Shaw[/url]
Help, my database is corrupt. Now what? by Gail Shaw[/url]
September 21, 2009 at 9:05 am
I think the rule was you leave about 1GB for the OS, unless you are on x32, going above 6GB of RAM. Somewhere around 6-8GB, I heard you are using a significant amount of RAM for paging space.
Not sure on x64 if you need to leave more of the OS as RAM increases.
September 21, 2009 at 9:25 am
Thanks all
September 21, 2009 at 9:31 am
I read that in different white papers for setting up SQLserver 2008. I dont remember where though. Quite a few were saying to leave 10% for the OS and rest for SQL.
Also stated was to make the page file 1.5 times of the memory left for the OS.
PS : Edited to add the pagefile config
-Roy
September 21, 2009 at 9:56 am
thanks a lot for all the suggestions.
September 21, 2009 at 2:04 pm
On any system with more than about 12GB of memory, you need to leave much more memory available to the OS. On a system with 32GB of memory, I would set the max memory to no more than 28GB - leaving at least 4GB to the OS.
Jeffrey Williams
“We are all faced with a series of great opportunities brilliantly disguised as impossible situations.”
― Charles R. Swindoll
How to post questions to get better answers faster
Managing Transaction Logs
September 21, 2009 at 3:01 pm
I'll agree with Jeff on this one. We are planning a move to blades with 32 GB of RAM and I am planning on leaving 4 GB available for the OS as well.
Viewing 15 posts - 1 through 14 (of 14 total)
You must be logged in to reply to this topic. Login to reply