[BUG] Lite - PerfMon first values spike skews graph

[dphugo]

Component

Lite

Performance Monitor Version

2.1.0

SQL Server Version

SQL Server 2022 (RTM-CU16)

Windows Version

Windows 11 23H2

Describe the Bug

1. Under the Server Tab -> Perfmon the initial/first values that load creates a spike on the graph, which causes a skew on the graph.
   • This seems incorrect as subsequent values are significantly smaller than the initial values.
   • It seems to be the aggregation of values shown for the first timestamp.
2. The initial graph's X-axis (timestamp) initializes towards the right, whereas I was expecting it to load more towards the origin axis.
   • Most other graphs starts the timestamp on the origin (to the left) on the X-axis.

Steps to Reproduce

1. Open Lite Edition

2. Open Server Tab

3. Select Perfmon Tab

4. Wait for collection to complete
   - First values loaded seems incorrectly aggregated on first timestamp

5. Select different Counter Group (i.e. Memory Pressure, CPU / Compilation, etc.)
   - First values loaded seems incorrectly aggregated on first timestamp

Expected Behavior

1. Initial / first values loaded for the graph should only be for the timestamp at which it ran, not an aggregation of some kind for that initial timestamp.
2. Initial timestamp on the X-axis load close to \ on origin to the left, like most other graphs.

Actual Behavior

1. Initial / first values loaded for the graph seems to be an aggregation of some kind that is shown on the initial timestamp.
2. Initial timestamp on the X-axis loads towards the end (right) of the X-axis.

Error Messages / Log Output

No error messages.

Screenshots

All Counters:

Memory Pressure:

CPU / Compilation:

IO Pressure:

TempDB Pressure:

Lock / Blocking:

Additional Context

I'm only using Lite at the moment, so not sure whether this would apply to the Full edition as well.

[erikdarlingdata]

Thanks for the detailed report and screenshots, @dphugo! This was a great catch.

The fix is up in PR #483 — the first data point for cumulative counters (PerfMon, WaitStats, FileIO, MemoryGrants) now stores a baseline and returns 0 instead of the raw cumulative value, which is what was causing the spike.

This will show up in the next nightly build and in subsequent full releases as well.