I agree with that,
But the real question is to understand why the different pools in SQL need to use the memory up to 64GB? SQL should not be starving the OS and with it using almost 64GB it is starving the OS. So using DBCC MemoryStatus is the way to track what pools in SQL are using what portions of the memory and troubleshooting accordingly. ( Glad I have Kalen Delaney's Inside SQL Storage Engine book, it's a super big help in troubleshooting these issues and understanding the design issues behind SQL and how it uses resources) Also remember that when you read the values they should be in 8K pages, so number X8K is the memory being used. Z Edward Ziots Network Engineer Lifespan Organization MCSE,MCSA,MCP+I, ME, CCA, Security +, Network + [email protected] Phone:401-639-3505 -----Original Message----- From: Ben Scott [mailto:[email protected]] Sent: Thursday, May 07, 2009 4:50 PM To: NT System Admin Issues Subject: Re: Memory monitoring question On Thu, May 7, 2009 at 3:50 PM, Christopher Bodnar <[email protected]> wrote: > OK, I've got this SQL 2005 server (x64 W2K3) with 64G of memory and I'm > looking at the PF usage # which has me worried: > But if I look at the % Usage of the pagefile in Perfmon it shows only 11%, > which seems good. I also look at Memory Pages Output/sec and it's always 0, > which is also good. Right. Task Manager mislabels things for reasons known only to Microsoft. When Task Manager says "PF Usage" it really means "Commit Charge", which has nothing to do with page file usage. > But my Memory committed bytes is ~64G, almost at the > amount of physical memory. I'm wondering why this is not paging more ... MS SQL Server dynamically allocates and releases memory from OS, in response to the load on the system. See: http://support.microsoft.com/kb/321363 So commit charge is high because MS-SQL Server is using most of the RAM on the system, because the system doesn't need it for anything else (you said load was low). The theory is that if one has the RAM, one intends for it to be used, not sitting idle. Not everyone agrees with the particular approach Microsoft uses to address that, and it makes multi-workload tuning kind of complicated, but that's the expected behavior from MS-SQL. If your server (or VM instance) is dedicated to MS-SQL, then it's actually desirable. -- Ben ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
<<image001.jpg>>
