WordPress: set minRam floors so first-boot install doesn't OOM#67
Open
fxck wants to merge 1 commit into
Open
Conversation
Every app service runs `wp core install` at first boot (base initCommands, gated by zsc execOnce). On the 0.125 GB platform default, that spike (php-fpm ~113 MB + wp-cli ~90 MB) OOM-killed the init process, and --retryUntilSuccessful turned it into a crash loop. verticalAutoscaling reacts too slowly for a sub-second spike, so the floor must absorb it. - AI Agent appdev + Remote (CDE) app: minRam 1 + maxContainers 1 (dev workstations also run composer/wp-cli in-container over SSH; dev uses SSHFS so pin a single container). - AI Agent appstage + Stage app: minRam 0.5 (install-spike only). - HA Production app: minRam 0.5 under the existing cpuMode DEDICATED (0.5, not 1, to avoid wasting RAM across up to 6 dedicated containers; steady-state scales up from the floor). - Small Production already had minRam 0.5; Local has no app service. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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
1 participant
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.
The bug
Deploying the WordPress recipe's app-bearing envs OOM-kills at first boot. Every app service runs
wp core installviarun.initCommands(zsc execOnce wpinit … initialize.sh) — the correct phase for a DB-writing bootstrap (build has no DB, prepare has no files). But the app services were left at the 0.125 GB platform default, and the install spike (php-fpm master+workers ≈ 113 MB + wp-cli ≈ 90 MB) exceeds that.--retryUntilSuccessfulthen turns the single OOM into a crash loop.Observed on
appdev:verticalAutoscalingreacts in 10–20 s and cannot absorb a sub-second spike, so — per the platform's own scaling guidance — the fix is aminRamfloor, set in import.yaml (it's not azerops.yamlfield).The fix (per-env
minRam, measured, not guessed)appdevminRam: 1+maxContainers: 1appstageminRam: 0.5appminRam: 1+maxContainers: 1appminRam: 0.5appminRam: 0.5(under existingcpuMode: DEDICATED)app0.5— unchanged1 GB for the dev workstations (they also run composer/wp-cli in-container over SSH) with
maxContainers: 1(dev uses SSHFS — multiple containers conflict). 0.5 GB for the install-spike-only prod/stage apps. HA stays at 0.5 (not 1) to avoid wasting RAM across up to 6 dedicated containers; steady-state autoscales up from the floor.Derived from a per-env audit against the platform provisioning rules + measured RAM figures on a live php-nginx@8.4 WordPress container.
Not changed (already handled)
The AI-Agent env's
appdev/appstageshare one DB and both run install at first boot, butinitialize.shguards withwp core is-installed, so the second container skips cleanly;--retryUntilSuccessful+priority: 10on the stores cover datastore-readiness. No app-repo change needed.