This Knowledgebase article provides a summary of the problem and a selection of Microsoft Knowledge Base articles that have helped address the issue. The information is presented to assist in resolving the problem, please check for up-to-date advice from Microsoft.
Memory Fragmentation. What is it?
Memory fragmentation is a problem that plagues all Microsoft Exchange installations. The problem is akin to file fragmentation on a disk, except that it is in memory and impacts Exchange performance. It does not mean physical RAM, and it is not that the Virtual Memory is not available; just the size of the blocks available are too small. For example, you have 500Mb of free Virtual Memory available but the largest free block is 8Mb.
Once blocks of memory become smaller than 32MB, you get the following Events in the Windows Application event log:
9582 Warning = resolve by restarting Microsoft Exchange services / rebooting server [action within 72 hrs].
9582 Errors = block sizes falling to < 16MB. Exchange experiences severe performance degradation. To resolve restart exchange or reboot exchange server [action urgent].
The presence of the warning messages may in itself not be of concern if they are only logged for a couple of hours during peak times. If the warning continues to be logged every hour throughout the day and into off-peak hours, then this would indicate a problem. The presence of one or two warnings is not of immediate concern. If the warnings become errors, then this is a concern for the Exchange services and would suggest that Exchange performance is degraded.
Benefits of Neverfail for Exchange
Although the problem is known to exist in Exchange, the presence of Neverfail Heartbeat for Exchange can be used to manage the problem effectively, while minimizing the impact.
- Users can manually switch so that the secondary is active. Some time later, they can switch back to the primary. This will have the effect of restarting the services on the affected server with only minimal service downtime.
- If a reboot is required, then the user can switch, shutdown Neverfail, reboot the primary server and then restart Neverfail, allow to sync up and then switch back to the primary server, thus limiting the total downtime.
Use Perfmon to help predict when the problem may occur. For more information about monitoring memory fragmentation, please see Microsoft Knowledge Base article:
In-store antivirus scanning is known to cause/aggravate this problem. The antivirus software must be running on the server itself to cause this. See the Microsoft knowledge Base for additional information.
Plan for Resolution, Windows 2000
Note: Implement these steps one at a time. Do not simply implement them all. Move down the list, apply the fix, and then run Exchange to see if the problem persists after each step. Exchange must be restarted between each fix. Ideally, reboot the server.
- Install SP3 for Exchange 2000.
- Use the latest Scsiport.sys driver.
- Install SP4 for Windows 2000 (mandatory for Neverfail).
- If RAM > 1GB HeapDeCommitFreeBlock. Please see Microsoft Knowledge Base article http://support.microsoft.com/?id=315407 .
- Decrease store database cache size. Please see Microsoft Knowledge Base article http://support.microsoft.com/?id=266768 .
- Setting Initial Memory %. Please see Microsoft Knowledge Base article http://support.microsoft.com/?id=810883 . This may require the Post SP3 Hotfix only if setting the registry value has no effect.
How-to troubleshoot it
It is possible that some housekeeping may reduce the occurrence of the fragmentation.
- Run the mailbox cleanup agent (This is recommended prior to performing any mailbox migration).
- Perform and offline defragmentation - ensure there is a backup before you begin this task.
- Once complete, you will need to create a new backup - please see the Microsoft knowledgebase on how to perform this.
Additional information may be found at:
Neverfail for Exchange