Summary
cpu_scheduler_stats sometimes stores several rows under a single collection_time for one server. That should not be possible:
CpuSchedulerStatsCollector is written to return exactly one row per run.- Every
collection_log run for that collector records rows_collected = 1.
The extra rows are not copies of each other. They are different snapshots that share one timestamp. So "the newest scheduler reading" is ambiguous, and the fleet card's Threads chip and the WPF card's Threads row can show either snapshot from one refresh to the next.
Evidence
DARLING01, last 24 hours, read-only:
| Server |
Collections with more than one row |
Most rows under one timestamp |
Distinct collections |
| SQL2025 |
31 |
13 |
1,236 |
| AG1 |
9 |
2 |
1,430 |
| SQL2017 |
6 |
3 |
1,290 |
| SQL2022 |
6 |
3 |
1,250 |
| AG2 |
5 |
2 |
1,427 |
| SQL2019 |
5 |
4 |
1,265 |
| SQL2016 |
3 |
3 |
1,326 |
One of the SQL2025 pairs, at 2026-09-22 22:33:09.382452:
collection_id values 639257087035687248 and 639257087035687249, consecutive.- Every column is identical except
total_current_workers_count (104 against 27) and available_physical_memory_kb (48,793,972 against 48,794,012).
These are two runs' readings with one run's timestamp.
Where to look
The fault is somewhere between the run that produces the row and the batch writer that stamps collection_time. A retried run, or a queued run flushed together with the next one, could explain it. The collector's own query is not the cause: it collapses to one row.
Other one-row-per-run tables may do the same thing. memory_stats showed no ties in the same sample.
Related
Found while working on #3895. The fleet reads now take the newest row per server through a per-server LIMIT 1. That breaks a tie arbitrarily, exactly as the DISTINCT ON it replaced did, so #3895 changes nothing here either way.
Summary
cpu_scheduler_statssometimes stores several rows under a singlecollection_timefor one server. That should not be possible:CpuSchedulerStatsCollectoris written to return exactly one row per run.collection_logrun for that collector recordsrows_collected = 1.The extra rows are not copies of each other. They are different snapshots that share one timestamp. So "the newest scheduler reading" is ambiguous, and the fleet card's Threads chip and the WPF card's Threads row can show either snapshot from one refresh to the next.
Evidence
DARLING01, last 24 hours, read-only:
One of the SQL2025 pairs, at
2026-09-22 22:33:09.382452:collection_idvalues 639257087035687248 and 639257087035687249, consecutive.total_current_workers_count(104 against 27) andavailable_physical_memory_kb(48,793,972 against 48,794,012).These are two runs' readings with one run's timestamp.
Where to look
The fault is somewhere between the run that produces the row and the batch writer that stamps
collection_time. A retried run, or a queued run flushed together with the next one, could explain it. The collector's own query is not the cause: it collapses to one row.Other one-row-per-run tables may do the same thing.
memory_statsshowed no ties in the same sample.Related
Found while working on #3895. The fleet reads now take the newest row per server through a per-server
LIMIT 1. That breaks a tie arbitrarily, exactly as theDISTINCT ONit replaced did, so #3895 changes nothing here either way.