VMware ESXi and vSphere Cluster Management

Understanding the Performance Graph in Process Explorer

Learn how to read Process Explorer's CPU, Private Bytes, and I/O throughput history graphs for an individual Windows process.

Process Explorer is a Windows process-inspection utility that provides detailed information about running processes and their resource usage. Its Performance Graph view charts recent activity for one selected process, helping you understand how that process behaves over time.

What the Performance Graph shows

To open the view, select a process in Process Explorer and open its process properties. The Performance Graph appears alongside other process detail views, such as Performance and Threads.

The graph view is process-specific. It shows the selected process's recent CPU, private-memory, and input/output activity rather than the usage of the entire computer. System-wide tools, such as Windows Task Manager's overall performance pages, answer a different question.

A current value tells you what is happening now. A history graph adds context: it can reveal sustained usage, short-lived bursts, idle periods, or gradual changes that are easy to miss in a single instantaneous measurement.

Performance Graph components

Graph	What it measures	Key interpretation details	Visual indicator
CPU usage history	The selected process's recent share of available processor time	Use the history to distinguish sustained load from short spikes and idle periods. Hover over a point for the CPU percentage and time of day.	Top graph
Private Bytes history	Memory committed by the process for its private use	A continuing upward trend can justify investigation into memory retention or leak-like behavior, but does not prove a defect by itself.	Middle graph
I/O throughput history	Recent input/output transfer activity performed by the process	Compare the two lines to understand whether activity is mostly reads, writes, or a mixture.	Bottom graph
Total I/O traffic	The combined volume of process reads and writes	Read and write activity together make up total I/O traffic.	Blue line
Write traffic	The portion of I/O activity consisting of writes	When the pink line is close to the blue line, much of the process's I/O is write activity.	Pink line

Reading the CPU usage history graph

The top graph tracks the selected process's recent CPU usage. CPU usage is the portion of available processor time consumed by a process. CPU time is the processor execution time attributed to that process.

Hover over a point in the graph to reveal the process's share of total CPU time at that point and the corresponding time of day. This lets you connect a peak with an action, such as opening a document, starting an export, or running a scheduled task.

The value is an aggregate process view. It is not separated into individual logical processors or CPU cores. A logical processor is a schedulable CPU execution unit, often corresponding to a core or hardware thread. Use the graph to judge the process's overall CPU activity, not to identify which logical processor was busy.

Sustained high usage: a broad, elevated section suggests continuing computation or another workload that repeatedly consumes processor time.
Short spike: a narrow peak suggests brief work, such as parsing, compilation, compression, or a response to a user action.
Idle period: a low or flat section indicates that the process used little CPU during that interval. It may have been waiting for input, I/O, a timer, or another process.

Reading the Private Bytes history graph

Private Bytes are memory committed by a process for its private use. Committed memory is memory for which Windows has committed backing resources. The middle graph records the recent history of that committed private-memory amount.

Private Bytes are different from CPU usage: CPU describes processor activity, while Private Bytes describe committed private memory. They are also different from the working set. A working set generally describes memory pages currently resident in physical RAM, whereas Private Bytes focuses on committed memory belonging privately to the process. A process can therefore have a large or changing Private Bytes value without showing the same pattern in CPU usage.

Watch the shape of the trend while the application performs repeated work. A rise followed by a stable plateau may be normal allocation and reuse. Private Bytes that continue rising through repeated, comparable operations can be relevant when investigating possible memory-retention or memory-leak behavior. Treat that pattern as evidence for further testing, not as proof of a leak on its own.

Reading the file and device I/O throughput graph

The third graph shows the process's recent I/O throughput, meaning the rate at which the process performs input/output transfers. Total I/O traffic is the combined volume of the process's read and write activity.

The blue line represents total I/O traffic.
The pink line represents write traffic.
Read traffic can be inferred by comparing total I/O traffic with write traffic. When total traffic is substantially above write traffic, reads account for much of the difference.

Bursts may correspond to loading files, saving documents, writing logs, copying data, database work, or communicating with a device. The graph identifies the process's I/O behavior, but it does not by itself identify the specific file or device responsible.

Interpreting all three graphs together

CPU, Private Bytes, and I/O histories describe different dimensions of process activity. Looking at the same time period across all three graphs is more informative than treating any one metric as a complete diagnosis.

High CPU with limited I/O: the process may be computation-heavy, such as calculating, transforming, compressing, or rendering data.
High I/O with modest CPU: storage, device, or other input/output activity may be a major part of the workload. The process may be waiting for transfers or using efficient system calls.
High CPU and high I/O together: the process may be actively reading or writing while also processing the data.
Rising Private Bytes over a long run: the process may be retaining allocations or caches. Compare repeated workloads and investigate further.
Low CPU during an apparent delay: the process may be waiting for I/O, synchronization, a timer, or another dependency rather than actively computing.

Practical investigations

Investigating a CPU spike

Select the application process and inspect its CPU history.
Hover over the high point to identify the CPU percentage and time of day.
Compare that time with a user action, scheduled task, refresh, or other event.
Determine whether the peak was brief or part of sustained usage.

Remember that the graph is not a per-core or per-processor breakdown. A high process value describes aggregate CPU activity.

Checking for growing private memory use

Observe the Private Bytes trend while the process performs repeated, comparable work.
Look for a stable pattern that returns to a similar level versus a continuous upward trend.
If growth persists, collect additional evidence with a suitable memory-analysis method and a controlled workload.

Persistent Private Bytes growth is a reason for further investigation, not conclusive evidence of a memory leak by itself.

Identifying write-heavy activity

Inspect the I/O graph during a suspected save, logging, export, or copy operation.
Compare the pink write line with the blue total-I/O line.
If the pink line is near the blue line, writes account for most of the observed I/O traffic.

Separating computation from storage activity

Compare all three graph histories over the same interval.
High CPU with limited I/O suggests computation-heavy processing.
High I/O with modest CPU suggests that file, device, or other I/O activity is a major part of the workload.
Use the timing of the patterns to compare them with the operation being tested.

Common graph patterns and likely interpretations

Observed pattern	Possible meaning	Recommended next check
Sustained CPU usage	Ongoing computation, repeated processing, or a busy loop	Hover over representative points, correlate the time with an operation, and inspect the Threads view if the responsible execution path is unclear.
Brief CPU spike	Short processing burst triggered by an action, timer, or scheduled task	Use the hover time to correlate the spike with application or system events.
Steadily rising Private Bytes	Growing retained allocations, caches, or possible memory-leak behavior	Repeat the workload, compare runs, and use additional memory analysis before drawing a conclusion.
High total I/O with high write traffic	Write-heavy activity such as saving, logging, exporting, or copying	Correlate the burst with the operation and investigate the responsible file or device with a more targeted tool.
High total I/O with relatively low write traffic	Read-heavy or mixed activity; much of the traffic is likely reads	Compare the difference between total and write traffic, then investigate the relevant input source or device.

Moving from graphs to detailed views

The Performance Graph is a starting point for diagnosis. If a trend needs more detail, use the adjacent Performance view to examine aggregate process metrics and the Threads view to inspect individual threads.

For example, a sustained CPU trend may prompt a thread-level investigation, while unusual memory or I/O behavior may require more detailed process metrics and resource-specific tools. The graph tells you when a pattern occurred and what kind of activity changed; the adjacent views can help explain which part of the process deserves closer inspection.

Troubleshooting cautions

Do not confuse a process-specific graph with system-wide resource monitoring.
Do not read aggregate CPU usage as a per-core breakdown.
Do not treat Private Bytes growth alone as proof of a memory leak.
Do not assume an I/O burst identifies the exact file or device responsible.
Use hover times and repeated observations to correlate graph patterns with real operations.