It took three days, countless idiotic comments (some too obscene for us to approve), and more than a little patience, but finally somebody bothered to do what anybody with half a clue could have done all along. SirBruce, one of our new favorite readers, actually took the time to fire-up the only performance monitoring tool that matters (ironically, called “Performance Monitor”), and start logging the Committed Bytes counter.
What he found was that, as we tried to explain in various other posts here, Committed Bytes does not count cache and/or superfetch-related memory allocations. Rather, it parallels (though does not exactly follow – it’s still a separate counter) the “In Use” value from the Resource Monitor utility that everyone in the blogosphere keeps parroting. All of which is important because, as SirBruce noted in his comment, such a result just might prove we were right all along.
You see, just as SirBruce so elegantly demonstrated with “Perfmon,” we, too, query the Committed Bytes counter directly – in the case of our Tracker Agent, via the Performance Data Helper (PDH) libraries. We see what “Perfmon” sees, and those data points reflect the fact that Committed Bytes is indeed accurately representing a fairly close approximation of the real physical memory use in the system. This is true regardless of whether superfetch is enabled or disabled – or even exists – for the system being monitored. They are two completely different entities, and as Mr. Kipling was known to say, “neither the twain shall meet.”
For example, on my own development system – a quad-core workstation with 8GB of RAM – the Committed Bytes counter in “Perfmon” typically hovers within a few hundred MB of what Resource Monitor is reporting as “In Use” memory. If I fire-up a bunch of memory intensive tasks (my personal favorite is VMware Workstation with a few 1-2GB VMs and the memory configuration set to keep everything in RAM), Committed Bytes will increase virtually in lock-step with the “In Use” value in RM.
Likewise, if I start closing VMs, Committed Bytes drops, again in virtual lock-step with “In Use.” And, if I really push the system, so that Committed Bytes/”In Use” memory is pegged at or near the 8GB mark (i.e. my PC’s total RAM size). the other critical “Perfmon” counters we record with our agent – Memory\Pages In/sec and Paging File\% Usage – start to climb rather quickly.
Which is why we factor all three of the above counters into our final Peak Memory Pressure Index calculations. Because when these three counters climb above the thresholds we’ve defined for the WCPI calculation process, it means that your PC really is running out of memory.
Folks, this isn’t rocket science. Anyone with any real experience monitoring Windows performance in the real world – and no, playing with Task Manager or Resource Monitor in your mom’s basement doesn’t qualify – knows we’re right. And now one of our fine readers has done the honor of vindicating us.
Bravo, SirBruce, for not sticking your head in the sand and actually bothering to think before feeding into the frenzy of idiocy that has taken over the blogosphere on this issue.