1756d496e59ed937f11b53f562a9808802da354d
4 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
|
1756d496e5 |
detect-memory: raise PHP_WORKER_ESTIMATE_MB default 60→128
All checks were successful
Cloud Apache Container / Build-and-Push (74) (push) Successful in 1m22s
Cloud Apache Container / Build-and-Push (80) (push) Successful in 1m20s
Cloud Apache Container / Build-and-Push (81) (push) Successful in 1m15s
Cloud Apache Container / Build-and-Push (82) (push) Successful in 1m19s
Cloud Apache Container / Build-and-Push (83) (push) Successful in 1m17s
Cloud Apache Container / Build-and-Push (84) (push) Successful in 1m25s
Cloud Apache Container / Build-and-Push (85) (push) Successful in 1m16s
Cloud Apache Container / Build-FPM-Images (74) (push) Successful in 1m17s
Cloud Apache Container / Build-FPM-Images (80) (push) Successful in 1m14s
Cloud Apache Container / Build-FPM-Images (81) (push) Successful in 1m21s
Cloud Apache Container / Build-FPM-Images (82) (push) Successful in 1m16s
Cloud Apache Container / Build-FPM-Images (83) (push) Successful in 1m15s
Cloud Apache Container / Build-FPM-Images (84) (push) Successful in 1m23s
Cloud Apache Container / Build-FPM-Images (85) (push) Successful in 1m15s
Cloud Apache Container / Build-Shared-httpd (push) Successful in 27s
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.
|
||
| e81b0df5b8 |
Reduce idle PHP-FPM memory footprint
All checks were successful
Cloud Apache Container / Build-and-Push (74) (push) Successful in 2m22s
Cloud Apache Container / Build-and-Push (80) (push) Successful in 2m7s
Cloud Apache Container / Build-and-Push (81) (push) Successful in 2m16s
Cloud Apache Container / Build-and-Push (82) (push) Successful in 2m13s
Cloud Apache Container / Build-and-Push (83) (push) Successful in 2m23s
Cloud Apache Container / Build-and-Push (84) (push) Successful in 3m31s
Cloud Apache Container / Build-and-Push (85) (push) Successful in 2m2s
Cloud Apache Container / Build-FPM-Images (74) (push) Successful in 2m21s
Cloud Apache Container / Build-FPM-Images (80) (push) Successful in 1m23s
Cloud Apache Container / Build-FPM-Images (81) (push) Successful in 2m51s
Cloud Apache Container / Build-FPM-Images (82) (push) Successful in 1m16s
Cloud Apache Container / Build-FPM-Images (83) (push) Successful in 2m4s
Cloud Apache Container / Build-FPM-Images (84) (push) Successful in 2m6s
Cloud Apache Container / Build-FPM-Images (85) (push) Successful in 1m17s
Cloud Apache Container / Build-Shared-httpd (push) Successful in 26s
Opcache: - memory_consumption: 128MB → 64MB (most WordPress sites use <40MB) - max_accelerated_files: 10000 → 4000 (sufficient for WordPress) - revalidate_freq: 2s → 60s (reduce stat() calls in production) - enable_cli: Off (don't cache scripts run from command line) FPM workers: - process_idle_timeout: 10s → 5s (faster worker teardown when idle) - max_requests: 500 → 200 (recycle workers sooner to release leaked memory) These changes primarily reduce the baseline memory of idle containers where opcache was reserving 128MB even for small sites. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> |
|||
| c78167871c |
Add shared httpd + PHP-FPM-only container architecture
Some checks failed
Cloud Apache Container / Build-and-Push (74) (push) Successful in 2m22s
Cloud Apache Container / Build-and-Push (80) (push) Successful in 3m14s
Cloud Apache Container / Build-and-Push (82) (push) Has been cancelled
Cloud Apache Container / Build-and-Push (83) (push) Has been cancelled
Cloud Apache Container / Build-and-Push (84) (push) Has been cancelled
Cloud Apache Container / Build-and-Push (85) (push) Has been cancelled
Cloud Apache Container / Build-FPM-Images (74) (push) Has been cancelled
Cloud Apache Container / Build-FPM-Images (80) (push) Has been cancelled
Cloud Apache Container / Build-FPM-Images (81) (push) Has been cancelled
Cloud Apache Container / Build-FPM-Images (82) (push) Has been cancelled
Cloud Apache Container / Build-FPM-Images (83) (push) Has been cancelled
Cloud Apache Container / Build-FPM-Images (84) (push) Has been cancelled
Cloud Apache Container / Build-FPM-Images (85) (push) Has been cancelled
Cloud Apache Container / Build-Shared-httpd (push) Has been cancelled
Cloud Apache Container / Build-and-Push (81) (push) Has been cancelled
Separate Apache and PHP-FPM into distinct container roles to reduce per-customer memory overhead on shared servers. Adds three new images: - Dockerfile.fpm: PHP-FPM only (no Apache), listens on TCP port 9000 - Dockerfile.shared-httpd: Apache only (no PHP), with SSL and proxy_fcgi - Existing Dockerfile unchanged for standalone mode Key changes: - detect-memory.sh: CONTAINER_ROLE env var (combined/fpm_only/httpd_only) controls the memory budget split - create-php-config.sh: FPM_LISTEN env var for TCP port vs Unix socket, added /fpm-ping and /fpm-status health endpoints - New entrypoints for each container role - tune-mpm.sh for hot-adjusting Apache MPM settings - shared-vhost-template.tpl with proxy_fcgi and SSL on port 443 - CI/CD builds all three image types in parallel Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> |
|||
| 87c4f2befc |
Optimize Apache & PHP-FPM memory for lower idle usage
All checks were successful
Cloud Apache Container / Build-and-Push (74) (push) Successful in 2m31s
Cloud Apache Container / Build-and-Push (80) (push) Successful in 1m54s
Cloud Apache Container / Build-and-Push (81) (push) Successful in 1m51s
Cloud Apache Container / Build-and-Push (82) (push) Successful in 1m52s
Cloud Apache Container / Build-and-Push (83) (push) Successful in 2m39s
Cloud Apache Container / Build-and-Push (84) (push) Successful in 1m58s
Cloud Apache Container / Build-and-Push (85) (push) Successful in 1m51s
Switch PHP-FPM from pm=dynamic to pm=ondemand (zero idle workers), auto-detect container memory via cgroups to calculate appropriate limits, and generate Apache MPM config at runtime. All tuning values are now overridable via environment variables. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> |