Large tokens can wreak havoc on an organization. For an Exchange environment, it can be devastating. Some common problems that will occur include:
- Event 2020, “The server was unable to allocate from the system paged pool because the pool is empty” in the application event log
- Event 333, “An I/O operation initiated by the Registry failed unrecoverably. The Registry could not read in or write out or flush one of the files that contain the system’s image of the Registry.” in the system event log
- Inability to logon to a box
- Server reboots itself
The chart below shows that as users logon in the morning the size of the page pool allocation increases because the size of the users’ token.
A computer with 4 GB of RAM and the /3GB switch and /USERVA = 3030 has a max size for page pool of 245 MB. The warning level would be considered 200 MB and critical would be 220 MB. With 8GB of RAM you have reduced the page file size to 215 MB thus reducing the warning level to 170 MB and 200 MB for critical.
As I did some more research I came across a couple articles that explained this problem in greater detail.
The excerpt below is from the article http://support.microsoft.com/kb/912376. This article talks about known issues with large tokens and page pool memory issues.
If you are within these limits, and the server is reporting errors that are related to paged pool memory depletion, it is likely that the initial paged pool memory allocation is less than expected. This can be caused by hardware demands, by device drivers, or by memory tuning that reduces initial paged pool memory allocation even more. Large memory configurations, for example, more than 4 GB of physical RAM, are the most common cause of this problem.
Each byte of physical RAM that is installed in a server requires some kernel memory to address and manage it. The more RAM that is installed, the more kernel address space must be reserved for it. Address space may be borrowed from paged pool memory to satisfy this demand.
We recommend that you do not install more than 4 GB of physical RAM in a server that is dedicated to running Exchange Server 2003. Exchange Server will make efficient use of up to 4 GB of RAM. However, Exchange Server will not take advantage of additional RAM even if it is available. Servers that support the Hot Add Memory feature can also cause significant reductions in the availability of paged pool memory. Even if no more than 4 GB of RAM is installed, address space may be reserved for the theoretical maximum amount of hot-add RAM that could be installed.
You can use a kernel debugger to view the size of initial paged pool memory and other kernel memory allocations.
The articles also talks about a couple performance counters to monitor.
It is easy to determine how much paged pool memory is currently being used. Windows Task Manager displays paged pool usage in the Kernel Memory area on the Performance tab. You can also monitor the use of paged pool memory over time with the MemoryPool Paged Bytes counter in Windows System Monitor.
More info can be found here: http://msexchangeteam.com/archive/2006/02/27/420684.aspx
Also, the following information is from http://support.microsoft.com/kb/912480.
You should install this fix only if you’ve already optimized token usage in your environment according to the suggestions in the Knowledge Base article, and you still are unable to reclaim as much memory as you need.
The hotfix does not get rid of token memory usage problems altogether. (Only moving to a 64-bit platform will really solve this problem.) But, as we committed to you before, we will continue to do everything we can to help you manage kernel memory limitations that impact Exchange scalability on the 32-bit platform. This hotfix and Knowledge Base article are our first deliveries on that promise.
Token bloat can cause serious technical and financial issues for an organization. Take caution that your organization has a good group management strategy in place and that SIDHistory only stays around as long as it is needed.