Claude Code 1756d496e5 detect-memory: raise PHP_WORKER_ESTIMATE_MB default 60→128 ...

The 60 MB worker estimate was optimistic for plugin-heavy WordPress
and WooCommerce stacks. Concrete measurement on alphaone 2026-06-01:

  Container memory : 1024 MiB (later 2048 MiB)
  Pool sized by formula : pm.max_children = (1024-100)/60 = 15
  Actual per-worker RSS : ~193 MB (anon+file+shmem from kernel OOM dumps)
  Worst-case peak       : 15 × 193 MB ≈ 2.9 GB

That math put traffic-burst peak demand well over the container cap,
producing 1,586 cumulative oom_kills across alphaone's two containers
over 18 days and intermittent fork-starvation for unrelated tenants
on the host.

128 MB is a more realistic baseline: closer to actual WP+Woo+page-
builder worker footprint, still conservative enough that lighter
sites continue to get reasonable concurrency. The matrix at common
container tiers:

  Tier (MiB)  | old children | new children | new peak demand
  256         | 2 (floored)  | 2 (floored)  | ~256 MB
  512         | 6            | 3            | ~384 MB
  768         | 11           | 5            | ~640 MB
  1024        | 15           | 7            | ~896 MB
  2048        | 15 (capped*) | 15           | ~1.9 GB
  (* old formula returned 32 at 2 GiB but production containers were
    booted at lower tiers and never recalculated; see whp01 audit.)

Existing containers keep their boot-time pm.max_children until they
are recreated — this change only affects new containers. Customers
or operators can override per-container via FPM_MAX_CHILDREN env.

2026-06-01 08:23:09 -07:00

4.8 KiB

Executable File

Raw Blame History

View Raw