patternsqlMinor
App domain is marked for unload due to memory pressure
Viewed 0 times
dueapppressureunloadmarkedformemorydomain
Problem
In my sql server log (2005 SP4) I have this message every couple of seconds :
"AppDomain XXX [DataBase.dbo[runtime], YYY] is marked for unload due to memory pressure"
Our server :
-
Intel Xeon CPU X5675 x 2 (6 core) 3.07Ghz
-
Awe enabled
I read many article about memtoleave or vas, but I don't get how to diagnose my problem.
Any idea ?
"AppDomain XXX [DataBase.dbo[runtime], YYY] is marked for unload due to memory pressure"
Our server :
- Windows Server 2003 R2 Enterprise Edition SP2
- 32 Gb RAM
- Physical Address Extension
-
Intel Xeon CPU X5675 x 2 (6 core) 3.07Ghz
-
Awe enabled
- We have CLR code in SQL Server
- -g2048 on startup (I'm no DBA, and this value was set by a former emplyee)
I read many article about memtoleave or vas, but I don't get how to diagnose my problem.
Any idea ?
Solution
Microsoft has a KB article about this behavior. You got a 32-bit OS with 32-bit application, so the process' address space is 4 GiB. AWE can be used to access more memory, but it is limited only for buffer pool usage. As per the documentation:
The SQL Server buffer pool can fully utilize AWE mapped memory;
however, only database pages can be dynamically mapped to and unmapped
from SQL Server's virtual address space and take full advantage of
memory allocated through AWE. AWE does not directly help supporting
additional users, threads, databases, queries, and other objects that
permanently reside in the virtual address space.
Short-term solution: review that your CLR code minimizes memory usage.
For a long-term solution, upgrade to 64-bit.
Addendum
Kimberly Tripp has written a white paper about CLR stuff from DBA point of view. She's got a few nice queries and Perfmon counters that are of use for tracking CLR resource use.
The SQL Server buffer pool can fully utilize AWE mapped memory;
however, only database pages can be dynamically mapped to and unmapped
from SQL Server's virtual address space and take full advantage of
memory allocated through AWE. AWE does not directly help supporting
additional users, threads, databases, queries, and other objects that
permanently reside in the virtual address space.
Short-term solution: review that your CLR code minimizes memory usage.
For a long-term solution, upgrade to 64-bit.
Addendum
Kimberly Tripp has written a white paper about CLR stuff from DBA point of view. She's got a few nice queries and Perfmon counters that are of use for tracking CLR resource use.
Context
StackExchange Database Administrators Q#63720, answer score: 4
Revisions (0)
No revisions yet.