Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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 serverfault.com/questions/254908/… –  tormozit Apr 2 '11 at 12:00

1 Answer 1

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:

http://www.dabcc.com/article.aspx?id=10571
http://blogs.msdn.com/b/david.wang/archive/2006/02/14/more-on-virtual-memory-memory-fragmentation-and-leaks-and-wow64.aspx

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

http://blogs.technet.com/b/markrussinovich/archive/2008/07/21/3092070.aspx
http://blogs.technet.com/b/markrussinovich/archive/2008/11/17/3155406.aspx
http://blogs.technet.com/b/markrussinovich/archive/2009/03/26/3211216.aspx

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

http://support.microsoft.com/kb/325044

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

 
discard

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.