Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Not long ago I've spotted very interesting tool RamMap. I found on several servers running our x32 software that PAGE TABLE grows very quickly – 1.2 GB per day (of 10GB all). Also NONPAGED POOL grows 300MB per day.

  1. Can anybody explain usual reasons for this?
  2. How can i get size of PAGE TABLE from code (for exaple API function or WMI class)?
  3. Can it be decreased, cleared or ... to free up RAM?

We have programming and executing platform called 1C (Russian business oriented platform). One process is like a manager over the others, which are launched on the schedule and are terminated by rules and perform different kinds of data processing including exchange with another data bases using COM. In other words i can’t tell what is happening on the platform level (it is hidden from us). We have some not fast (=)) support from platform developers – they still not answered on our questions for this issue.

We have different OS configurations (2003 and 2008 Server, x32 and x64). Everywhere page table grows. Speed of growth is proportional to number of processes running simultaneously (on the main server 30-40). When PAGE TABLE reaches 50-70% of RAM server begins to fail in different ways.

share|improve this question
It seems I just made one step forward to solve the problem. See new topic about memory leak suspicion… – tormozit Apr 2 '11 at 12:00

Looks like a virtual memory fragmentation issue; memory is being allocated and deallocated continuously, and each time new Page Table Entries (PTEs) are being created in order to keep track of memory pages; your assertion that lots of processes are being created and terminated and that this page table increase is proportional to the number of running processes really points in this direction. Also, PTEs are usually kept in nonpaged memory (they're vital to the memory menager, so should always reside in memory); this also explains the increase in the nonpaged pool usage.

Some links about this:

These are also very helpful in understanding what could be going on:

Unfortunately, there isn't much you can do about this; this page is Exchange-specific, but maybe it can give you some tips:

This is a kind of problem no application restart can fix; only a full server reboot can clear virtual memory fragmentation.

Using a x64 system can help here, as the virtual address space is considerably bigger; but it will not fix the fragmentation issue, so it won't fix the increased PTE usage, either.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.