Bucket the Darling viewer's Overview CPU/wait/memory lanes server-side (#4234)

[erikdarlingdata]

Part of #4234.

Why

The Overview lanes' CPU, total-wait and memory reads each return one row per collection (or, for CPU, one row per ring-buffer sample) with no cap: 10,080 rows over 7 days for CPU, 9,840 for total-wait and memory, per the issue's own measurement. This buckets three of the five reads in T2b's brief to TrendBudget.Chart's width, the same sizing contract PR #4304 (T1, merged as c51b43f) applied to the Wait Stats and Perfmon charts.

What changes

Done, committed and pushed (T2b):

• ViewerDataService.Cpu.cs (CpuUtilizationSql, GetCpuUtilizationAsync): bucketed. Both CPU columns are gauges (ruling item 2), averaged per bucket with no MAX/peak column (neither the CPU tab's own chart nor the Overview lane draws one). CpuUtilizationSample's two fields moved int -> double. The read gained an optional endUtc parameter (width sizing only); both real call sites now pass it.
• ViewerDataService.OverviewLanes.cs (TotalWaitTrendSql/GetTotalWaitTrendAsync, MemoryTrendSql/GetMemoryTrendAsync): bucketed. Wait is a rate (summed delta over summed interval, generalizing WaitTrendsSql's per-type case to one aggregate series, seriesCount=1). Memory's four MB metrics are gauges, averaged, no peak.
• Both bucketed reads implement ruling item 3: when EVERY bucket a call returns holds exactly one physical collection, every point is stamped at that collection's own raw time instead of the bucket grid.
• Darling.Tests: updated the CPU and Overview-lanes SQL-text source checks and added bucket-width source checks (ruling item 6) for the Overview reads.
• Decided, no code change: Overview's blocking and deadlock lanes. BlockingTrendSql/DeadlockTrendSql stay at their existing fixed one-minute DATE_TRUNC — the MCP twin of this family stays fixed at one minute too, with no ladder or cap, and T3a's measurement put the real 7-day row counts at 297 and 41 (sparse, event-driven rows, not a dense per-collection series). Flagged for T2a/T3b's Lite lane to mirror "leave it."

Done this pass (T2c — finishing the PR: ran the tests T2b wrote but never ran, fixed what broke, filled the gap):

• Ran ViewerCpuTempDbLivePostgresTests and ViewerOverviewLanesLivePostgresTests against a real Postgres 18 + TimescaleDB rig for the first time. Both passed as committed, but two other test classes did not once actually exercised:
  • ViewerCpuTempDbSqlTests still pinned the pre-bucketing CPU SQL shape (DoesNotContain("AVG(")/GROUP BY, ORDER BY sample_time) against the now-bucketed CpuUtilizationSql — 2 of 4 tests failed. The Overview file's equivalent SQL tests had been updated correctly; the CPU file's had not. Updated them for the bucketed shape and added the ruling item 6 bucket-width source check the CPU read was still missing.
  • TimeHonestyRungTests.BothWindowedCpuReads_PreferTheStoredUtcInstant_AndKeepTheDeSkewAsTheFallback pins the viewer's and the MCP get_cpu_utilization's CPU-read projections byte-identical at fixed column positions. WPF trend charts never adopted the #3897/#3960 bucket contract: at the "Last 7 days" window one chart reads 85–170 k raw rows, and the pickers re-run a week-long DISTINCT every refresh #4234 nested the viewer's copy one indent level deeper inside a new raw CTE, which shifted every line 4 columns over — genuinely breaking the literal pin (not a bug in the bucketing itself). Changed the comparison to collapse whitespace runs instead of comparing fixed columns, and split the ORDER BY sample_time / $3 assertions per reader, since bucketing changed both for the viewer only (bucket ordinal instead of the raw column; $3 is now a bucket width, not absent).
• Added the two missing live tests ruling item 6 asks for, for all three reads (CPU, total-wait, memory) — 6 new tests total: a 7-day window returns at most TrendBudget.Chart.AutoPoints rows (proves the cap actually bites: seeded at the real 1-per-minute cadence via a bulk generate_series insert so 10,080 rows doesn't cost a per-row round trip), and point equality with the old per-collection read when every bucket in a window holds exactly one physical collection, seeded off the minute grid (:37 seconds) so a fix that floors to the bucket grid line instead of the raw timestamp would fail it. Proved each of the 6 fails on the old shape: temporarily forced a fixed 1-minute bucket width for the budget tests, and forced every point to stamp at bucket_start instead of its raw timestamp for the singleton tests; both variants turned every corresponding test red, then were reverted (no net source diff from this proof).
• Resolved the PerformanceMonitor.Common.csproj merge conflict against origin/dev (which landed the same InternalsVisibleTo for PerformanceMonitor.Darling.Viewer via WPF Wait Stats and Perfmon trend charts bucket server-side (#4234) #4304/T1, as this PR's own description predicted): kept one copy, combined the two comments so it names both the Wait Stats/Perfmon charts (already on dev) and this PR's Overview lanes/CPU chart.
• Merged origin/dev twice (once at the start of this pass, once again after adding the new tests, since dev moved again in between) — both merges clean except the one csproj conflict above; rebuilt and re-ran the full required class set after each.

Not done: Performance Trends moved to lane T2d's PR.

Test plan

• Darling/Darling.Tests/Darling.Tests.csproj builds with 0 Warning(s), 0 Error(s) after every commit (5 rebuilds this pass).
• Live round-trip against a real Postgres 18 + TimescaleDB rig (DARLING_TEST_PG set, migrations applied) — run for the first time this pass.
• Full required class set for this PR, all against the live rig where the class has a live component:
  • ViewerCpuTempDbSqlTests: 12 passed (2 fixed, 1 added, rest unchanged).
  • ViewerCpuTempDbLivePostgresTests: 6 passed (4 existing + 2 new).
  • ViewerOverviewLanesSqlTests: 9 passed (unchanged from T2b).
  • ViewerOverviewLanesLivePostgresTests: 7 passed (3 existing + 4 new).
  • ViewerTrendBucketWidthSqlTests: 3 passed.
  • ViewerNameListCacheTests: 5 passed.
  • ViewerTrendBucketingLiveTests: 6 passed.
  • TimeHonestyRungTests: 8 passed (1 fixed).
  • TimeHonestyRungLivePostgresTests: 1 passed.
  • DocCommentHygieneTests: 77 passed.
  • Total: 134 passed, 0 failed, 0 skipped.
• Proved once (twice, actually — once for the budget cap, once for the singleton passthrough) that each of the 6 new tests fails on the old shape; see above.
• git merge origin/dev, twice; clean except the one documented csproj conflict; rebuilt and re-ran the class set above after each.
• Full suite: CI runs it, per the brief.

What the coordinator should double-check

1. The blocking/deadlock "leave as is" call — a real design decision with Lite-parity consequences, made by T2b.
2. The "per-execution average" vs. "same rate formula as MCP" conflict T2b flagged for Performance Trends — now lane T2d's decision to make, on their own PR.
3. This PR now merges origin/dev cleanly as of this pass (merge commits included); the one real conflict (the PerformanceMonitor.Common.csproj InternalsVisibleTo comment, from WPF Wait Stats and Perfmon trend charts bucket server-side (#4234) #4304 landing the same entry) is resolved by keeping one copy with a combined comment.
4. WPF trend charts never adopted the #3897/#3960 bucket contract: at the "Last 7 days" window one chart reads 85–170 k raw rows, and the pickers re-run a week-long DISTINCT every refresh #4234 must stay open until T2d's Performance Trends PR and any remaining parts (T2a/T3b's Lite mirror) land.

CHANGELOG entry

SECTION: Changed
ENTRY:

• Darling viewer's CPU, Overview wait and Overview memory charts bucket server-side over long windows ([Bucket the Darling viewer's Overview CPU/wait/memory lanes server-side (#4234) #4327]) - The CPU chart, and the Overview tab's total-wait and buffer-pool lanes, used to return one row per ring-buffer sample or per collection with no cap: about 10,080 rows each for a 7-day window at one collection a minute. Postgres now buckets all three to a fixed row budget, matching the sizing already applied to the Wait Stats and Perfmon trend charts. A window narrow enough that every bucket holds exactly one sample or collection still renders each point at its own exact timestamp rather than a bucket boundary, so short windows look unchanged.
  REF:
  [Bucket the Darling viewer's Overview CPU/wait/memory lanes server-side (#4234) #4327]: Bucket the Darling viewer's Overview CPU/wait/memory lanes server-side (#4234) #4327

🤖 Generated with Claude Code

https://claude.ai/code/session_01FVjn4PBJN71NQXdFo6ZxNQ