docs: fold P3 engine-CPU decomposition into D1, fallback, and fit window

Dawn's P3 replica-subtraction measurement (2026-07-30, receipts in
RESEARCH/BB_PUBLIC_REDIS_P3_ENGINE_CPU_DECOMPOSITION.md) resolves the
open <25%-decomposition caveat and lands three spec updates:

- D1 gets its gated input: ~40% of primary engine CPU is write-apply +
  publish propagation (the never-read replica carries 7.8pp of 19.5pp);
  ~60% is client-facing and divides only as connections/subscriptions
  redistribute. Notes the A4 dependency (propagation confines to the
  owning shard only after P2) plus two measurement cautions: the
  pub/sub-vs-keyed regression split is unidentifiable (r=0.997), and
  the apparent sublinearity is a ~1.1% fixed baseline.
- Fallback row corrected: the replica is not idle — 7.8% is its own
  unsheddable load on a ~3.8d doubling, saturating alone in ~14 days.
  Kickoff's 'idles at 7%' framing removed.
- Problem statement gains the measured fit window: sharp onset
  2026-07-21 ~18:00Z; fits must start post-onset; curr_connections
  moves in pool-config plateaus, not demand. Onset unattributed
  pending deploy history.

Summary timeline row updated to the fitted ~7d-to-80% with the
degraded-fallback note. Model and configs untouched; doc only.

Co-authored-by: npub1qyvc0c5kl4gqv2fd97fsk46tu378sqgy35vc83rvgfwne90sel7s0ed67d <011987e296fd5006292d2f930b574be47c7801048d1983c46c425d3c95f0cffd@buzz.block.builderlab.xyz>
Signed-off-by: npub1qyvc0c5kl4gqv2fd97fsk46tu378sqgy35vc83rvgfwne90sel7s0ed67d <011987e296fd5006292d2f930b574be47c7801048d1983c46c425d3c95f0cffd@buzz.block.builderlab.xyz>
This commit is contained in:
npub1qyvc0c5kl4gqv2fd97fsk46tu378sqgy35vc83rvgfwne90sel7s0ed67d
2026-07-30 14:01:46 -04:00
parent acfb537fbc
commit 3292b35db1
+33 -9
View File
@@ -83,6 +83,13 @@ profile `bb-public-operations-ro`).
scaling is dead: same-family bigger instances have identical single-core scaling is dead: same-family bigger instances have identical single-core
speed; r8g (Graviton4) buys ~25–30% single-thread ≈ 1.5 days at the current speed; r8g (Graviton4) buys ~25–30% single-thread ≈ 1.5 days at the current
doubling rate. doubling rate.
- **Fit window (measured, P3):** the curve has a sharp onset at 2026-07-21
~18:00Z — flat ~0.55% for the preceding five days, then exponential within
one 15-min bin (subscribed channels 74→1303 in four hours at a pinned
connection count). Growth fits must start after the onset or they mix two
regimes. `curr_connections` moves in pool-config plateaus (40.0 → 74.9 →
~280) and must not be read as demand. The onset is unattributed; confirming
what reached bb-public at 18:00Z needs deploy-history access.
## System Model ## System Model
@@ -622,11 +629,15 @@ keep CPU <80% during resharding — resharding is compute-intensive, and doing
it while the engine core saturates is the worst time. The countdown clock is it while the engine core saturates is the worst time. The countdown clock is
the argument for starting G1 now, not for heroics at 90%. the argument for starting G1 now, not for heroics at 90%.
**Fallback (curve outruns the plan):** replica read offload **Fallback (curve outruns the plan):** replica read offload. Downgraded but
(`buzz-001-002` idles at 7%) buys roughly one doubling. Note the coupling: in not dead (P3, measured 2026-07-30): the replica is **not idle** — its 7.8%
cluster mode, replica reads lean on exactly the replica-repair path fixed in engine CPU is its own write-apply + propagation load, unsheddable, on its own
redis-rs #2120/#2223, so the version floor is a prerequisite for the fallback exponential (doubling ~3.8d; saturates alone in ~14 days serving zero reads).
too, not just hygiene. Offload still buys primary time, but the destination is a node ~6 days behind
the primary on the same clock — size against its remaining headroom, not
"93% free". Note the coupling: in cluster mode, replica reads lean on exactly
the replica-repair path fixed in redis-rs #2120/#2223, so the version floor
is a prerequisite for the fallback too, not just hygiene.
## Conformance (test matrix, gate G2) ## Conformance (test matrix, gate G2)
@@ -733,9 +744,22 @@ REDIS_CLUSTER_PRODUCTION_PRIOR_ART.md`, `…_OPEN_SOURCE_PRIOR_ART.md`,
in (2026-07-30): keyed-command growth is uniform (no hot path in the in (2026-07-30): keyed-command growth is uniform (no hot path in the
command mix), and the hottest-shard imbalance factor is ~1.5x fair share command mix), and the hottest-shard imbalance factor is ~1.5x fair share
at 4 shards (see §Sharded Pub/Sub Conversion) — do not size by at 4 shards (see §Sharded Pub/Sub Conversion) — do not size by
`current/N`. Caveat: per-family `rate x latency` accounts for well under a `current/N`. The earlier caveat that per-family `rate x latency` explains
quarter of measured engine CPU, so the decomposition is not a complete under a quarter of engine CPU is now resolved by measurement (P3,
cost model; D1 stays open. replica-subtraction natural experiment: the never-read replica carries
7.8pp of the primary's 19.5pp): **~40% of primary engine CPU is
write-apply + publish propagation; ~60% is client-facing** (reads, Lua,
connection I/O, subscriber delivery) and divides only as connections and
subscriptions redistribute across shards. One dependency inside the 40%:
write-apply partitions by key unconditionally, but by A4 the propagation
component confines to the owning shard **only after P2 lands** — with
classic pub/sub, every node processes every publish. So the ~40% is the
shardable fraction *with* P2, an upper bound without it. Two further
cautions from the same measurement set: engine CPU cannot be split
pub/sub-vs-keyed by regression (rates collinear at r=0.997; subsampled
shares swing 4%→37%), and the apparent sublinearity of CPU vs. rate is a
~1.1% fixed baseline, not economies of scale — do not project on the
exponent. D1 stays open pending the P2/imbalance-adjusted arithmetic.
- **D2 — Pattern subscribers stay classic.** Accepted in design; re-opens - **D2 — Pattern subscribers stay classic.** Accepted in design; re-opens
only if G0 shows their volume is non-trivial. **Measured 2026-07-30: D2 only if G0 shows their volume is non-trivial. **Measured 2026-07-30: D2
holds.** All publishers are lifecycle/admin-rate (code trace, verified holds.** All publishers are lifecycle/admin-rate (code trace, verified
@@ -763,4 +787,4 @@ REDIS_CLUSTER_PRODUCTION_PRIOR_ART.md`, `…_OPEN_SOURCE_PRIOR_ART.md`,
| Sharded pub/sub necessity | Documented fact | Axiom A4 (Valkey cluster spec) | | Sharded pub/sub necessity | Documented fact | Axiom A4 (Valkey cluster spec) |
| Sharded pub/sub at scale | **No prior art** | Buzz-specific load/reconnect gate in G2 | | Sharded pub/sub at scale | **No prior art** | Buzz-specific load/reconnect gate in G2 |
| Shard count | **Open** | G0 profile (D1) | | Shard count | **Open** | G0 profile (D1) |
| Timeline | ~8–10 days of runway at current doubling | G1 starts now; fallback = replica offload | | Timeline | ~7 days to 80% on the primary (fitted, post-onset window) | G1 starts now; fallback = replica offload (degraded — replica not idle, ~14d to its own saturation) |