Page table fast growth
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.
- Can anybody explain usual reasons for this?
- How can i get size of PAGE TABLE from code (for exaple API function or WMI class)?
- 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.
Solution 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.