Share via

PTE depletion, handle leaks and You

  • Article

Applies to:  Windows 2000 Server/Advanced Server, Windows 2003 32bit Server, Exchange 2000/2003

PTEs 

Ok, so one of the most overlooked resources we run into with performance and availability problems is the availability (or lack thereof) of Free Page Table Entries.  What is a PTE?  It's basically an I/O partition table, if you will.  Wikipedia has an awesome link with 8x10 color glossy photos, with circles and arrows and a paragraph on the back explaining what each one is, so I'll point you there.  Cliff Huffman also has an excellent post on PTEs here that specifically talks about Windows.

So anyway, running out of Free Table Entries is bad, because it causes system hangs, sporadic lock ups, general unresponsiveness, etc.  These symptoms present themselves in Exchange as general slow performance or service unavailability.

You manage your available PTEs in Windows with the boot.ini and also the SystemPages registry key.  Generally speaking for an Exchange Server that is properly configured, you'll see your PTE values somewhere between 8000-16000.  A large number of PTEs (50k or so) may be a hint that you're not using the /3GB switch on your server.  A lower value generally means there is a problem.

This problem can either be a configuration issue, or if the PTE value is falling, a memory leak.

If you are dealing with a static low value and you've examined all the configuration settings and they all seem fine, but the value is still low (flagging in the EXBPA for example), then add /basevideo to your boot.ini.  The new agp/pci-e video drivers consume a lot of PTEs, and who needs the super-duper video card drivers on an Exchange box anyway?

If you are dealing with a leak, update your drivers for everything, NIC, HBA, Video, SCSI controller, you name it, update it.  If you've done all that and still haven't gotten the leak addressed, contact PSS to get one of us involved with your case.

Handles

Another resource people don't usually pay much attention to is handle count.  Excessive handle consumption can cause all kinds of non-paged kernel pool problems because they reside within that memory space.

If you have the symptoms of a memory leak but don't see what is causing it, check out the handle count in task manager.  You can do this by going to the Processes tab and selecting View/Select Columns and selecting Handles.  Handle usage varies by application and what it's doing at the time, but if you have an application with 100k handles open and your machine performance isn't the greatest, you may be dealing with a handle leak.  If you are, your non-paged pool kernel memory may also be high but not showing anything eating it up in poolmon.  This is because the handles don't appear to be taken into account on the poolmon monitor in some cases, so high consumption of handles by a resource don't end up under the process tag.

If you have a process with a high handle count, contact the vendor.

Documents on PTEs:

The effects of 4GT tuning on system Page Table Entries

How to Configure the Paged Address Pool and System Page Table Entry Memory Areas

Documents on Handles:

Well, here you can see the impact of high handle count:

Microsoft KB

Comments