Out of Memory Issues on 32 bit Windows

Posted by on April 23, 2010
Filed Under Performance Engineering | Comments Off


I seem to be seeing more instances of Windows applications getting out of memory conditions on servers with 4 GB of RAM than I used to.  It seems that like the 640K limit of DOS in the early days, the 2 GB limit of process space on 32 bit Windows is more frequently an issue.  The 2 GB limit for application space in Windows is well documented and discussed on-line.  I’m not going to re-hash it here.  Some of the more useful links are below.

What I wanted to do in this post is give a way to potentially make full use of the 2 GB of address space.  Johan discusses in his post how an out of memory condition can actually occur at less than 2 GB because RAM allocations need contiguous space.   He further explains how memory can get fragmented, leaving parts of it unusable.  What he doesn’t discuss is a Windows registry setting that can help prevent fragmentation from occurring, thereby allowing you to make full use of the 2 GB of process space.

The HeapDecommitFreeBlockThreshold registry entry determines how the heap manager decides what to do when memory is freed.  Microsoft recommends setting this entry on any servers that have over 1 GB of RAM, but, it doesn’t seem that this is very well published.  I have had several instances over the past couple of years where this setting allowed a process that was crashing at around 1.2 GB of private bytes to continue running up to the 2 GB limit.  The KB article on the setting is at http://support.microsoft.com/kb/315407.  I’ve never seen it cause a problem, and it has helped memory management in several situations.

The situation in which it may help is if you have at least 4 GB of RAM in your server, and you are using Windows server 2003 – 32 bit.  You should monitor the process that is having the out of memory error with perfmon, and watch the amount of Private Bytes being used.  If the process gets an out of memory condition when the Private Bytes value is less than 2 GB, the HeapDecommitFreeBlockThreshold setting may help.  Compare the Private Bytes for the process to the Virtual Bytes as described in the posting above by snakefoot.  This can be an indication of fragmentation.  The HeapDecommitFreeBlockThreshold setting should allow Windows to make better allocation decision, and let the process get more contiguous space allocated.

If the process is crashing when it has the full 2 GB of Private Bytes allocated, your options are limited.  You’ll have to change the application to somehow use less memory, or move to a 64 – bit version of the operating system.  By the way, 32 – bit versions of Linux have a 3 GB limit on process space, so if you can move your application to Linux, that may work for you.

Other related topics are PAE and the /3GB switch.  PAE is very useful if you’re using Intel CPU’s that support it.  The /3GB is a lot more tricky and can cause stability issues.  I’m not going to discuss those topics here, but some useful links are below.


Comments are closed.