Log in
::
Register
::
Not logged in
Home
Tags
Articles
Editorials
Forums
Scripts
Videos
Blogs
QotD
Books
Ask SSC
SQL Jobs
Training
Authors
About us
Contact us
Newsletters
Advertise
Write for us
Recent Posts
Recent Posts
Popular Topics
Popular Topics
Home
Search
Members
Calendar
Who's On
Home
»
SQL Server 2005
»
Administering
»
memory
12 posts, Page 1 of 2
1
2
»»
memory
Rate Topic
Display Mode
Topic Options
Author
Message
sandhyarao49
sandhyarao49
Posted Tuesday, May 27, 2008 10:29 AM
SSC Journeyman
Group: General Forum Members
Last Login: 2 days ago @ 8:57 PM
Points: 88,
Visits: 410
I have some doubt regarding memory management.
I have sql2005 on windows server 2003 ,64-bit
suppose if have 32 gb of ram, by default how much memory it will take.
As far i concerned by default os will take 2 gb of ram and remaining will be taken by the sql server as per demand.(but i think it will take not more than 2 gb)
could any one tell me that sql serrver memory management is dynamic or not.what exactly happens
Plz give some idea regarding memory management.
Post #507076
Manoj-485464
Manoj-485464
Posted Tuesday, May 27, 2008 10:51 AM
SSC-Enthusiastic
Group: General Forum Members
Last Login: Wednesday, February 04, 2009 7:34 AM
Points: 129,
Visits: 130
SQL and os will take the Memory as they needed. If you want to strict for SQL and OS, you may need to enable the AWE on SQL server side.
Manoj
MCP, MCTS (GDBA/EDA)
Post #507092
Michael Earl-395764
Michael Earl-395764
Posted Tuesday, May 27, 2008 12:05 PM
SSCrazy
Group: General Forum Members
Last Login: Friday, October 09, 2009 7:14 PM
Points: 2,732,
Visits: 23,071
You are on 64 bit, so don't worry about AWE.
By default, SQL server will dynamically allocate memory. This is configurable to a window of dynamic memory (set a min and max) or you can set it to allocate a specific amount of memory.
SQL 2000 did not do an efficient job of dynamically allocating memory, but SQL 2005 does it rather well (MS made big improvements here).
Every system is different. It is best to start with dynamic memory allocation and do some performance testing to see if you need to set limits or specify memory allocation manually.
Post #507147
Steve Jones - Editor
Steve Jones - Editor
Posted Tuesday, May 27, 2008 12:24 PM
SSChampion
Group: Administrators
Last Login: Today @ 2:53 PM
Points: 23,148,
Visits: 6,912
Tend to agree with Michael. Monitor and observe the system. AWE isn't needed for 64-bit and my guess is SQL will keep building cache and run to 30GB unless you limit it.
Post #507165
Marios Philippopoulos
Marios Philippopoulos
Posted Tuesday, May 27, 2008 2:31 PM
Ten Centuries
Group: General Forum Members
Last Login: Monday, March 15, 2010 8:54 PM
Points: 1,200,
Visits: 2,080
To get the total current size of your buffer pool run the following:
SELECT
SUM( multi_pages_kb +
virtual_memory_committed_kb +
shared_memory_committed_kb +
awe_allocated_kb ) AS [Used by BPool, KB]
FROM
sys.dm_os_memory_clerks
WHERE
[type] = 'MEMORYCLERK_SQLBUFFERPOOL'
Taken from INSIDE MICROSOFT SQL SERVER 2005, QUERY TUNING AND OPTIMIZATION by Kalen Delaney at el., which contains a good discussion of memory issues.
Another good tool is
DBCC MEMORYSTATUS
. It will give you the current size of the buffer pool, plus other components, such as the procedure cache.
Here is an excerpt from the output run on my server:
Buffer Counts Buffers
------------------------------ --------------------
Committed 786432
Target 786432
Hashed 722004
Stolen Potential 127447
External Reservation 0
Min Free 128
Visible 195584
Available Paging File 401426
Procedure Cache Value
------------------------------ -----------
TotalProcs 6878
TotalPages 54239
InUsePages 105
In the above sample, the procedure cache size is 54239 pages times 8 KB/page = 434 MB (roughly)
Post #507261
Marios Philippopoulos
Marios Philippopoulos
Posted Tuesday, May 27, 2008 2:44 PM
Ten Centuries
Group: General Forum Members
Last Login: Monday, March 15, 2010 8:54 PM
Points: 1,200,
Visits: 2,080
Steve Jones - Editor (5/27/2008)
Tend to agree with Michael. Monitor and observe the system. AWE isn't needed for 64-bit and my guess is SQL will keep building cache and run to 30GB unless you limit it.
It's true that because of the vast amount of virtual address space available in 64-bit, the need for AWE is greatly diminished.
However, memory allocated through AWE is locked in (will not get paged out), and that may be beneficial for app performance even in a 64-bit environment (albeit at the risk of starving other processes off of needed memory).
Post #507274
Wilfred van Dijk
Wilfred van Dijk
Posted Tuesday, May 27, 2008 11:52 PM
Right there with Babe
Group: General Forum Members
Last Login: Today @ 3:45 PM
Points: 745,
Visits: 839
You need AWE to prevent memory stealing by the OS.
Also make sure you have a minimum and maximum size. Don't set the maximum size to unlimited, or SQL will compete with your OS for the last MBs.
We have the same configuration and our max memorysize is 28GB (min size is 16GB)
Also, be aware of memory trashing if you do a large OS filecopy on that server.
You also get memory messages in your logfile when adding/deleting databases/snapshots, but these are ok.
Post #507437
Manoj-485464
Manoj-485464
Posted Wednesday, May 28, 2008 7:37 AM
SSC-Enthusiastic
Group: General Forum Members
Last Login: Wednesday, February 04, 2009 7:34 AM
Points: 129,
Visits: 130
I agree with Wilfred van Dijk. Wilfred van Dijk has explined very clearly.
Manoj
MCP, MCTS (GDBA/EDA)
Post #507669
Marios Philippopoulos
Marios Philippopoulos
Posted Wednesday, May 28, 2008 8:01 AM
Ten Centuries
Group: General Forum Members
Last Login: Monday, March 15, 2010 8:54 PM
Points: 1,200,
Visits: 2,080
Wilfred van Dijk (5/27/2008)
You need AWE to prevent memory stealing by the OS.
Also make sure you have a minimum and maximum size. Don't set the maximum size to unlimited, or SQL will compete with your OS for the last MBs.
We have the same configuration and our max memorysize is 28GB (min size is 16GB)
Also, be aware of memory trashing if you do a large OS filecopy on that server.
You also get memory messages in your logfile when adding/deleting databases/snapshots, but these are ok.
Memory stealing is not a concern, unless there are other non-OS essential apps running on the server, correct? (I'm thinking Exchange for example).
Are there other occasions where mem stealing would be an issue?
Post #507683
Wilfred van Dijk
Wilfred van Dijk
Posted Wednesday, May 28, 2008 9:02 AM
Right there with Babe
Group: General Forum Members
Last Login: Today @ 3:45 PM
Points: 745,
Visits: 839
If you don't enable AWE on a 64bit server you can get errors like "
A significant part of sql server process memory has been paged out. This may result in performance degradation
". for example, this can happen if you copy a lage filebackup to another server.
As a result, al your SQL processes are suspending, but I would say dying (I've had that experience)
Read the following articles:
http://blogs.msdn.com/psssql/archive/2007/05/31/the-sql-server-working-set-message.aspx
http://support.microsoft.com/kb/918483
http://msmvps.com/blogs/omar/archive/2007/09/19/a-significant-part-of-sql-server-process-memory-has-been-paged-out-this-may-result-in-performance-degradation.aspx
http://www.mcse.ms/message2444910.html
http://blogs.msdn.com/slavao/archive/2005/04/29/413425.aspx
Post #507749
« Prev Topic
|
Next Topic »
12 posts, Page 1 of 2
1
2
»»
Permissions
You
cannot
post new topics.
You
cannot
post topic replies.
You
cannot
post new polls.
You
cannot
post replies to polls.
You
cannot
edit your own topics.
You
cannot
delete your own topics.
You
cannot
edit other topics.
You
cannot
delete other topics.
You
cannot
edit your own posts.
You
cannot
edit other posts.
You
cannot
delete your own posts.
You
cannot
delete other posts.
You
cannot
post events.
You
cannot
edit your own events.
You
cannot
edit other events.
You
cannot
delete your own events.
You
cannot
delete other events.
You
cannot
send private messages.
You
cannot
send emails.
You
may
read topics.
You
cannot
rate topics.
You
cannot
vote within polls.
You
cannot
upload attachments.
You
may
download attachments.
You
cannot
post HTML code.
You
cannot
edit HTML code.
You
cannot
post IFCode.
You
cannot
post JavaScript.
You
cannot
post EmotIcons.
You
cannot
post or upload images.
Copyright © 2002-2010 Simple Talk Publishing. All Rights Reserved.
Privacy Policy.
Terms of Use