Partilhar via

Tracking page file reads and writes

  • Artigo

 

The only real way of knowing if a page file is actually being “read from” is to get a file IO trace. This can be collected and/or viewed with tools such as the Microsoft Performance Recorder/Analyzer, Microsoft Resource Monitor, or Sysinternals Process Monitor.

Using Resource Monitor

Resource Monitor is built into the operating system and can be launched from the Performance tab of Task Manager.

image

The Disk Activity pane in Microsoft Resource showing reads and writes to pagefile.sys.

The Disk tab shows the processes and files involved in live disk activity. This data comes from Event Tracing for Windows (ETW) and shows much more data than what performance counters can provide. In this case, we can see the file C:\pagefile.sys being written to by the System process.

Using Windows Performance Recorder/Analyzer

image

Microsoft Windows Performance Recorder/Analyzer is part of the free Windows Assessment and Deployment Kit (ADK) and can capture activity related to hard page faults and the processes and files associated with them. In this case, I used WPR to record Disk IO and File IO activity while forcing the system to use the page file. In the screenshot I am showing the Hard Faults chart within Windows Performance Analyzer (WPA) and I aggregated the data to show the files most involved with hard page faults and in this case it was C:\pagefile.sys. This is proof that most of the hard page fault activity was related to the page file in this case.

Using Sysinternals Process Monitor

Sysinternals Process Monitor (Procmon) can also show page file reads and writes. This can be done by enabling the Advanced Output option under Filter, Enable Advanced Output. Once enabled, set the filter to only show events where “Path is C:\pagefile.sys” or similar for other page files.

image

After capturing data for a few minutes, click Tools, File Summary to get more details of the number of reads and writes to the page file.

Hard page fault related performance counters

The performance counters \Memory\Page/sec, \Memory\Page Reads/sec, and \Memory\Page Inputs/sec measure hard page faults (faults that must be resolved by disk) which *may* or *may not* be related to a page file or a low physical memory condition. Hard page faults are a normal function of the operating system and happen when reading the portions of image files (DLLs and EXEs) as they are needed, when reading memory mapped files, or when reading from a page file. High values for these counters (excessive paging) indicate disk access (generally 4 KB per page fault on x86 and x64 versions of Windows and Windows Server), but again, they may or may not be related to page file activity, but they contribute towards disk usage which can increase the likelihood of system-wide delays assuming the related disk(s) are overwhelmed. Therefore, it is recommended to monitor the disk performance of the logical disks hosting a page file in correlation with these counters.

Note: \Memory\Page Writes/sec and \Memory\Page Output/sec do measure only page file writes.

In addition, the counter \Paging File(*)\% Usage provides us the usage, but not how often a page file is actually being accessed. In addition, hard page faults just mean disk access.

This is the reason why the Performance Analysis of Logs (PAL) tool measures a low memory condition that could cause system wide delays by taking many performance counters into consideration. The PAL tool has an analysis called Physical Memory Overwhelmed and creates a factious counter called \Memory\Physical Memory Overwhelmed. In this analysis, it analyzes for low physical memory ( \Memory\Available MBytes), page file usage ( \Paging File(*)\% Usage), and disk counters related to the page file(s) to determine if they are overwhelmed when the system is low on physical memory.

Comments