The Infamous 9582 Event (continued)

If you know what that event id number means check this out. 

[This is a continuation of my The Infamous 9582 Event post last week.]

 

Just as I blabbed about last week in my other post, Exchange 2000 turned up a new event ID to Exchange admins and support folks across the lands.  The 9582 events made their first appearance shortly after a lot of admins upgraded their servers to Exchange 2000 SP1 or higher.  As I was saying before, the problem of VMF (virtual memory fragmentation) has been around for a long time, but not until SP1 or higher did we actually come out and report it when the VMF hit a critical state.  For this blog entry I’ll focus on the improvements in Exchange 2003…

 

In E2K, a large portion of the Store.exe's memory is allocated for the ESE Buffer (a.k.a. JET Buffer).  This buffer is placed in the Store.exe VA (i.e., virtual address space).  This buffer acts as a software-based disk buffer to help relieve some of the pressure on the disk subsystem.  Remember, going to memory is much faster than going to disk!  Out of the box, E2K uses a hard-coded buffer size of 858Mb, regardless of the amount of RAM, memory configuration, or OS.  As many people now know, this buffer size can be adjusted through the msExchESEParamCacheSizeMax parameter in AD.  In most E2K 9582 cases, when trying to prolong the VMF, we decrease the size of the ESE cache.  By decreasing the size of the buffer, you leave additional free virtual memory for Store.exe to use during runtime.  Whenever decreasing the size of the buffer, you must consider the potential disk I/O increase.  As you take more of the database out of virtual memory, you run the risk of putting a lot more pressure on the disks where the database resides.

 

In Exchange 2003, the ESE buffer is allocated intelligently based on whether the /3GB switch is set in the boot.ini file.  If the /3GB has been set (per Q266096), then the ESE buffer is automatically tuned to 896Mb.  If the /3GB switch has not been set (indicating less then 1Gb of physical RAM), then the ESE buffer is tuned down to 576Mb.  This auto-tuning means that smaller servers will not run out of virtual memory because the Store.exe is using less of a buffer and leaving more for runtime operations.

<snipped to save space.  Check out the link>