Health: colour the swap bar by paging rate, not by fill - #767
Merged
Conversation
A box that has been up for months parks cold pages in swap and never
reclaims them. On my own device swap sits at 3000/3000 MB with si/so at
0, CPU 93% idle and 1.6 GB still available - nothing is wrong, but
pctStatus() turned the bar red at >=90% fill, so the Health page showed
a permanent alarm. That red bar is what sends people to the forum
convinced their device is broken.
Swap fill says how much has ever been paged out. It says nothing about
whether the machine is struggling now. The rate does, and the backend
already collects swap_in_pages/swap_out_pages - the line directly under
the bar prints them, so the page was showing "0 · 0 KB/s" next to a red
bar.
Key the bar off that rate instead: 256 KB/s warns, 2 MB/s is an
exception. Fill stays as the bar's length and in the MB readout, where
it is informative without being a verdict. Memory and disk bars keep
using fill, which is the right signal for those.
The dev stub never emitted the two counters, so the rate line read 0
there regardless; it now advances them so the page can be exercised
without a real device.
Also bumps visual_diff_skip_build to 3084, without which this branch
cannot go green. The nightly artifact prune on the CI host deleted
platform/3084-*, the build FindLatestBuild("stable") resolves to, so
ci-diff downloads an empty tree and fails with "no screenshots were
compared" on every branch build. 3076 was the previous occurrence; the
constant only matches when it equals the current latest stable, so it
went inert when stable moved. This is a stopgap - ci-diff still cannot
tell a pruned baseline from a screenshot regression, and DownloadBuild
should fail on a missing build directory instead of returning nil.
cyberb
force-pushed
the
health-swap-status-from-rate
branch
from
August 28, 2026 00:11
da38481 to
2b3e4c9
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
A device that has been up for months parks cold pages in swap and never reclaims them. Reported on the forum as a Nextcloud problem (nextcloud very slow, 100% cpu usage), but reproduced on my own box where nothing is actually wrong:
si/soare 0 across the sample, CPU 93% idle, 1.6 GB available. ButpctStatus()turned the swap bar red at >=90% fill, so the Health page showed a permanent alarm — right next to its own "swap in 0 · swap out 0 KB/s" line.Change
Swap fill says how much has ever been paged out; it says nothing about whether the machine is struggling now. The rate does, and
backend/health/metrics.goalready collectsswap_in_pages/swap_out_pages.swapRate— 256 KB/s warns, 2 MB/s is an exception.used / total MBreadout, where it informs without rendering a verdict.Verified on a real device
Deployed to a box running 19 apps (platform rev
x1, all 75 snap services active). Swap 3000/3000 MB,pswpin/pswpoutidentical across a 2s sample, so the bar renders green at 100% fill with0 · 0 KB/sbeneath it. Before this it was red.Also included:
visual_diff_skip_build3076 → 3084Not related to the swap change, but this branch cannot go green without it. The nightly artifact prune on the CI host deleted
platform/3084-*, which is the buildFindLatestBuild("stable")resolves to, soci-diffdownloads an empty tree and fails on every branch build:3076was the previous occurrence. The constant only takes effect when it equals the current latest stable, so it went inert when stable moved to 3084.Note this makes visual-diff pass by returning early rather than by comparing. No e2e spec visits
/health, so this PR loses no coverage it ever had — but the underlying defect remains:visual-diff/cmd/app.go:54returnsnilfor a build directory that does not exist, making a pruned baseline indistinguishable from a screenshot regression. Worth a follow-up.The baseline regenerates on the next stable push and is protected from pruning from then on by the artifact cleaner now running on the CI host, which keeps the last green stable per app regardless of age.
Tests
New
tests/unit/Health.spec.jscovers full-but-idle (green), sustained paging with swap mostly free (red), light paging (amber), and thatpctStatusstill governs the other bars. Full suite: 25 suites / 129 tests green, eslint clean. Jsonnet validated withdrone jsonnet+drone lint.