Skip to content

CONCEPT Cited by 1 source

Cache as workspace, CPU as work

Definition

Cache as workspace, CPU as work is an interpretation discipline for dashboard signals that share a 0–100% scale but describe structurally different system behaviour. Simeon Griggs (PlanetScale, 2026-03-30) canonicalises the asymmetry:

"At a glance, CPU and memory usage numbers look comparable because they share a 0–100% scale, but they describe very different behavior. CPU is work. Sustained high CPU means the database is spending time on work it cannot skip. … There is no 'good' kind of sustained high CPU usage. Memory is workspace. Postgres and the OS use spare RAM to avoid expensive disk reads. Higher use improves performance … most of the time."

(Source: sources/2026-04-21-planetscale-high-memory-usage-in-postgres-is-good-actually.)

The asymmetric interpretation

Signal Sustained high reading Operator action
CPU 80%+ Work queueing, tail latency climbing, no headroom for spikes Always problematic — tune workload or upgrade
Memory 80%+ (mostly cache) Warm working set, queries served from RAM Actively desirable
Memory 80%+ (mostly RSS) Memory pressure, OOM risk Problematic — investigate RSS drivers

The dashboard view shows the same "80%" for all three rows. The operator's first job is to disambiguate memory's contribution by decomposing into the four-category accounting.

Why the metaphor works

Griggs leads the post with the houseplant-over-watering parable: "Your empathy can lead to misinterpreting signals from your database. You don't like feeling overwhelmed, so you don't want your database overwhelmed either." The "workspace" metaphor names the failure: a database's cache memory is like a workshop's tool drawer — you want the drawer full of ready-to-use tools, because it means you don't have to go fetch them. A workshop at 20% drawer-fill is underutilising its working space; a workshop at 80% drawer- fill is running efficiently.

CPU has no equivalent beneficial-fullness semantics. CPU time spent is CPU time that had to be spent on work the database could not skip.

Companion signals

  • CPU high, tail latency high, queue depth climbing — CPU saturation, headroom exhausted.
  • Memory high, cache-hit-ratio high, disk I/O low — healthy cache utilisation (concepts/cache-hit-ratio-memory-pressure).
  • Memory high, cache-hit-ratio dropping, disk I/O climbing — working set outgrown RAM; cache thrashing.
  • Memory high, RSS climbing, OOM-kill markers present — memory pressure; process-memory leak or concurrency spike.

The last pattern is the five-signal correlated cluster for genuine memory pressure that Griggs names at the conclusion: "Rising RSS toward limits, OOM kills, unexplained restarts, and tail latency spiking together with heavy disk I/O when the working set is tight on RAM are the signals to act on."

Connection to alerting strategy

concepts/symptom-based-alerting prescribes alerting on customer-visible signals (latency, error rate), not on implementation-detail signals (memory %, CPU %). The cache- as-workspace discipline reinforces this: a memory-% alert fires on a dimension that is sometimes desirable and sometimes problematic, so the signal is ambiguous and produces alert fatigue. A latency + error-rate alert fires only when the ambiguity has resolved into customer-visible harm.

Seen in

Last updated · 550 distilled / 1,221 read