Performance monitoring misunderstanding in Windows XP Pro SP3 using Task Manager and System Monitor.
I am using Windows XP SP3 Pro. And I am monitoring a memory consumption on my system using perfmon.msc and Task Manager. I have set pagefile size to zero so it's disappeared on all my drives. That's just fine for demonstrating you strange thing I am concerned about. With this configuration Task manager shows 500 Mb usage in "PF usage" and "Page file usage history"(pagefile.sys wright? Because it's not named as , for example, "Pages usage" and "Pages usage history" respectively) Snapshot of memory indicators in Task Manager: Physical memory (K): Total - 2087084 Available - 1367600 System Cache - 871488 Commit Charge (K): Total - 552780 Limit - 1932700 Peak - 966628 Kernel Memory (K): Total - 63284 Paged - 45780 Nonpaged - 17504 Questions: 1. How it can be that with pagefile disabled entirely Task manager shows 550 Mb usage of PAGE FILE (not pages)? And in Perfmon.msc the Page Reads/Sec counter (which indicates HARD page faults only that is fetching pages from pagefile (from hard drive) having required page not in RAM) displays some activity in idle state and lots of activity when new program is being launched? And 550 Mb is not the value of totally consumed RAM (Total - Available != Commited). 2. What ACTUALLY is being displayed in "Commit Charge (K)" section the "Total" parameter and consequently in graphs "PF usage" and "Page file usage history" in XP SP3 pro? 3. Is there any patch for correcting this? PS: On Windows Server 2003 std. these counters appearing reasonably and are just fine.1 person needs an answerI do too
March 2nd, 2010 10:38am

In Windows Task Manager's Performance tab the "PF Usage" graph is the same value as the "Commit Charge (K) Total". Commit Charge does _not_ mean that the page(s) are written to the physical paging file on the hard drive, assuming that a page file is allocated, Commit Charge is the potential amount that can be written for the process(es). The page(s) can be in cache (waiting to be written to a paging file), or currently in use by another process if it is shared, etc. This is also where the Page Faults can occur, if the process requests the page and it is in cache or in shared use, it must be fetched resulting in a page fault. This is also why you see PF Usage, Commit Charge, Paged Kernel, and Page Faults on computers with 8GB+ memory and no applications currently running (just the desktop and processes). A computer such as this would have plenty of available fast RAM, and there would be no need to actually page to the hard disk, so the values are actually reflecting potential use or pages in cache etc. Since a large percentage of physical memory is used for various cachings, Page Files should never be disabled even on computers with 8GB+ physical RAM unless the user knows for certain that they are never exceeding the total physical memory at any time for all applications, processes, and caches. If stale pages cannot be moved out of fast physical memory to the paging file, allowing that fast memory to be utilized by other current processes, the size of the caching is reduced and overall system performance can suffer. Most of these forementioned values are not showing what is actually being written to the physical hard drive paging file.
Free Windows Admin Tool Kit Click here and download it now
March 16th, 2010 4:49am

Thank you for your reply, MrDRGreen . I know that "Commit Charge"(Total) is a mix of RAM and pagefile on hard disk. On Windows Server 2003 std, as I mentioned, "Commit Charge"(Total) is indeed equal to "Physical memory (Total)" MINUS "Physical memory (Available)" . But it's not the case of Windows XP SP3. A gap in calculation on XP is 150M or greater. There is no pagefile for clearly show you what is going on. I think that this is a bug of XP's Virtual Memory Manager (VMM).
March 16th, 2010 6:07pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics