August 23, 2012 at 4:19 am
Hi,
Operating system - Win server 2008 b4 bit enterprise edition
Version - SQL server 2008 R2 b4 bit enterprie edition
Physical Ram - 8GB
Server dedicated only running SQL 2008 R2, and single instance
Already configured the max memory 4.5 GB at SQL instance. but Sqlserver.exe using more than 5.5 GB in task manager.
what could be issues sqlserver not using under 4.5 GB memory even setting the max memory?
August 23, 2012 at 4:33 am
Not an issue, normal behaviour.
Max server memory sets the size of the buffer pool. There's also the non-buffer memory (CLR, linked server drivers, backup buffers, thread stacks, etc). That's allocated above and beyond the buffer pool. It's usually small, but that depends what you're doing. Lots of CLR and it'll be larger than normal.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
August 23, 2012 at 4:47 am
ok, understand why it is using more memory due to backup buffer, and thread stack..
In this server not enable CLR,
also Linked server not created..
each thread stack using 512 KB, so does thread stack should using under max memory only also inside buffer Pool?
August 23, 2012 at 5:29 am
No, thread stacks do not use memory in the buffer pool, they use the non-buffer memory.
CLR disabled does not mean no CLR. The system assemblies can still be used. There's a lot of other things that use the non-buffer memory as well.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
August 23, 2012 at 5:49 am
GilaMonster (8/23/2012)
No, thread stacks do not use memory in the buffer pool, they use the non-buffer memory.CLR disabled does not mean no CLR. The system assemblies can still be used. There's a lot of other things that use the non-buffer memory as well.
Thanks for reply..
I forget to mention first post, I did lock page memory in this server. SQL server service account added into Local Security Policy Setting in 64bit system.
Can we posssible to check there is lot of other things that are using non-buffer memory?
August 23, 2012 at 6:45 am
iirc it's covered in chapter 4 of this: http://www.simple-talk.com/books/sql-books/troubleshooting-sql-server-a-guide-for-the-accidental-dba/
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
August 24, 2012 at 6:03 am
please confirm.
I thought my production server is settle under memory usages.
I did configuration as below
1. set the max memory 6GB (dedicated SQL machine), total 8 GB.
2. configured Lock page memory
(service account add to the Local Security Policy Setting, It is always required to configure at 64bit system) also which accounts can use a process to keep data in physical memory, preventing the system from paging the data to virtual memory on disk.
Now SQLSERVR.EXE process consuming only 89MB only in Task manager till last 4 days, as per current workload process.
Before not configured Lock page memory, that time SQLSERVR.EXE process consuming only 5.5GB and max memory setting 6GB.
thanks
August 27, 2012 at 12:50 am
please confirm.
I thought my production server is settle under memory usages.
I did configuration as below
1. set the max memory 6GB (dedicated SQL machine), total 8 GB.
2. configured Lock page memory
(service account add to the Local Security Policy Setting, It is always required to configure at 64bit system) also which accounts can use a process to keep data in physical memory, preventing the system from paging the data to virtual memory on disk.
Now SQLSERVR.EXE process consuming only 89MB only in Task manager till last 4 days, as per current workload process.
Before not configured Lock page memory, that time SQLSERVR.EXE process consuming only 5.5GB and max memory setting 6GB.
thanks
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply