Groups | Blog | Home
all groups > sql server msde > march 2005 >

sql server msde : msde memory setting


Keeper
3/11/2005 12:31:12 PM
What memory settings should i configure to tune msde?

Sometimes it will be installed on a PC but at other times it will be an app
Keeper
3/11/2005 2:51:04 PM
i appreciate the information

thanx



[quoted text, click to view]
Andrea Montanari
3/11/2005 11:05:07 PM
hi,
[quoted text, click to view]

usually you should not manually "tune" SQL Server as it is tailored to self
configure it self...
on the other hand, SQL Server is very resources intensive, and is designed
to take advantage of all the installed available memory (in sys32 processes
limit :) )

and it's a very challenging taks to manual configure it for best
performance..
remember that memory usage is database and application dependent, but usage
and workloads dependent too...

Loosely speaking, SQL Server organize it's memory allocation in two distinct
regions, the "buffer pool" (BPool) and the "memory to leave" (MemToLeave)
regions. (I'm excluding use of AWE in order to provide easy understanding
and because MSDE does not admit it)..
so... the BPool is the primary region SQL Server uses for it's internal
matter, while MemToLeave consists of the virtual memory space within the 1gb
user mode address space and the memory not used by the BPool.

when SQL Server starts, it begins calculating the upper limit the BPool can
reach... if no MaxMemory is set, this value will be set to the amount of the
physical memory or the size of the user mode address space (1gb) , minus the
size of the MemToLeave, whichever is less..

by default, MemToLeave is set to 384mb, 128mb of them are for worker thread
stacks and 256mb for allocation outside the BPool, such as memory for OLE-DB
providers, linked server drivers, NetLib dlls, in process COM objects space
and memory requirements and so on..
when MaxMemory value is explicitally set, this upper limit will only address
BPool region needs...
so only the address space of BPool pages is limited by this configuration
value, while SQL Server memory requirememts outside BPool allocation are not
limited this way...

more, each connection, live or sleeping, will eat about 24kb of memory,
calculated as 12 KB + 3 times the Network Packet Size (default setting that
can be partially customized via sp_configure system stored procedure
modifying the 'user connections' setting), used to store the data structures
holding the connection 's context, as long as for buffer used to send and
receive the relative associated network streams (default to 4KB network
packet setting), that can be stolen from the buffer pool memory region
and/or the MemToLeave memory area...

not limiting the resources, SQL Server can reclaim that memory (up to 1 gb,
in our example) for it's uses, and it will perhaps release it only under
pressure by the OS claiming for additional memory, if it's the case, else it
will maintain that memory in order to cache pages and execution plans...
under OS pressure, SQL Server will try having the Lazy Writer releasing
resources, but you are not granted that this will occur, even if SQL Server
will always try to leave some memory for other OS needs, usually between 4
and 10mb of RAM... so, on SQL Server dedicated servers, you usually see
memory usage climbing to the top and staying there for long time, becouse of
SQL Server tends to keep pages read from disk in memory to increase further
and successive access to those pages, as long as query plans and so on... on
a heavy loaded server, if you add web server duty, you will have resources
contentions for sure...

I strongly advice you for
http://www.windowsitpro.com/Article/ArticleID/37908/37908.html and
http://www.windowsitpro.com/Article/ArticleID/37890/37890.html

another interesting readings:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsqldev/html/sqldev_03252004.asp
--
Andrea Montanari (Microsoft MVP - SQL Server)
http://www.asql.biz/DbaMgr.shtm http://italy.mvps.org
DbaMgr2k ver 0.10.0 - DbaMgr ver 0.56.0
(my vb6+sql-dmo little try to provide MS MSDE 1.0 and MSDE 2000 a visual
interface)
--------- remove DMO to reply

Andrea Montanari
3/11/2005 11:06:08 PM
hi,
[quoted text, click to view]

usually you should not manually "tune" SQL Server as it is tailored to self
configure it self...
on the other hand, SQL Server is very resources intensive, and is designed
to take advantage of all the installed available memory (in sys32 processes
limit :) )

and it's a very challenging taks to manual configure it for best
performance..
remember that memory usage is database and application dependent, but usage
and workloads dependent too...

Loosely speaking, SQL Server organize it's memory allocation in two distinct
regions, the "buffer pool" (BPool) and the "memory to leave" (MemToLeave)
regions. (I'm excluding use of AWE in order to provide easy understanding
and because MSDE does not admit it)..
so... the BPool is the primary region SQL Server uses for it's internal
matter, while MemToLeave consists of the virtual memory space within the 1gb
user mode address space and the memory not used by the BPool.

when SQL Server starts, it begins calculating the upper limit the BPool can
reach... if no MaxMemory is set, this value will be set to the amount of the
physical memory or the size of the user mode address space (1gb) , minus the
size of the MemToLeave, whichever is less..

by default, MemToLeave is set to 384mb, 128mb of them are for worker thread
stacks and 256mb for allocation outside the BPool, such as memory for OLE-DB
providers, linked server drivers, NetLib dlls, in process COM objects space
and memory requirements and so on..
when MaxMemory value is explicitally set, this upper limit will only address
BPool region needs...
so only the address space of BPool pages is limited by this configuration
value, while SQL Server memory requirememts outside BPool allocation are not
limited this way...

more, each connection, live or sleeping, will eat about 24kb of memory,
calculated as 12 KB + 3 times the Network Packet Size (default setting that
can be partially customized via sp_configure system stored procedure
modifying the 'user connections' setting), used to store the data structures
holding the connection 's context, as long as for buffer used to send and
receive the relative associated network streams (default to 4KB network
packet setting), that can be stolen from the buffer pool memory region
and/or the MemToLeave memory area...

not limiting the resources, SQL Server can reclaim that memory (up to 1 gb,
in our example) for it's uses, and it will perhaps release it only under
pressure by the OS claiming for additional memory, if it's the case, else it
will maintain that memory in order to cache pages and execution plans...
under OS pressure, SQL Server will try having the Lazy Writer releasing
resources, but you are not granted that this will occur, even if SQL Server
will always try to leave some memory for other OS needs, usually between 4
and 10mb of RAM... so, on SQL Server dedicated servers, you usually see
memory usage climbing to the top and staying there for long time, becouse of
SQL Server tends to keep pages read from disk in memory to increase further
and successive access to those pages, as long as query plans and so on... on
a heavy loaded server, if you add web server duty, you will have resources
contentions for sure...

I strongly advice you for
http://www.windowsitpro.com/Article/ArticleID/37908/37908.html and
http://www.windowsitpro.com/Article/ArticleID/37890/37890.html

another interesting readings:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsqldev/html/sqldev_03252004.asp
--
Andrea Montanari (Microsoft MVP - SQL Server)
http://www.asql.biz/DbaMgr.shtm http://italy.mvps.org
DbaMgr2k ver 0.10.0 - DbaMgr ver 0.56.0
(my vb6+sql-dmo little try to provide MS MSDE 1.0 and MSDE 2000 a visual
interface)
--------- remove DMO to reply


AddThis Social Bookmark Button