jknapp
03cca745f7
All checks were successful
Cloud Apache Container / Build-and-Push (74) (push) Successful in 1m18s
Cloud Apache Container / Build-and-Push (80) (push) Successful in 2m14s
Cloud Apache Container / Build-and-Push (81) (push) Successful in 3m21s
Cloud Apache Container / Build-and-Push (82) (push) Successful in 2m18s
Cloud Apache Container / Build-and-Push (83) (push) Successful in 2m15s
Cloud Apache Container / Build-and-Push (84) (push) Successful in 2m11s
Cloud Apache Container / Build-and-Push (85) (push) Successful in 2m22s
Cloud Apache Container / Build-FPM-Images (74) (push) Successful in 4m22s
Cloud Apache Container / Build-FPM-Images (80) (push) Successful in 3m46s
Cloud Apache Container / Build-FPM-Images (81) (push) Successful in 1m17s
Cloud Apache Container / Build-FPM-Images (82) (push) Successful in 1m21s
Cloud Apache Container / Build-FPM-Images (83) (push) Successful in 2m15s
Cloud Apache Container / Build-FPM-Images (84) (push) Successful in 2m21s
Cloud Apache Container / Build-FPM-Images (85) (push) Successful in 3m29s
Cloud Apache Container / Build-LiteSpeed-Images (81) (push) Successful in 31s
Cloud Apache Container / Build-LiteSpeed-Images (82) (push) Successful in 31s
Cloud Apache Container / Build-LiteSpeed-Images (83) (push) Successful in 30s
Cloud Apache Container / Build-LiteSpeed-Images (84) (push) Successful in 32s
Cloud Apache Container / Build-LiteSpeed-Images (85) (push) Successful in 31s
Cloud Apache Container / Build-Shared-httpd (push) Successful in 1m33s
Two correctness fixes and a tuning improvement.
CORRECTNESS:
1. Strip the stock 'extProcessor lsphp' from httpd_config.conf before
appending ours. Previously the stock block (hard-coded
PHP_LSAPI_CHILDREN=10 regardless of container memory) always won
because our APPEND fragment didn't include an extProcessor block.
detect-memory-litespeed.sh was computing LSAPI_CHILDREN but never
plumbing it anywhere — silent dead code.
2. Bump LSPHP_WORKER_ESTIMATE_MB from 96 → 115 per the 2026-06-02
memory-sizing finding (vantagehealth OOM-spawn loop). Each lsphp
carries ~115 MB shmem-rss accounted per worker. 115 MB matches the
real per-worker baseline.
TUNING (idle reduction, the original ask):
- LSAPI_MAX_IDLE_CHILDREN=2 (was CHILDREN/2 = 5 default)
- LSAPI_MAX_IDLE=60s (was 300s default)
- PHP_LSAPI_MAX_REQUESTS=500 (recycle workers, prevents bloat)
- memSoftLimit=1024M / memHardLimit=1500M per worker (RLIMIT_AS;
catches runaway scripts at the worker level, cgroup still backstops
the container)
Effective LSAPI_CHILDREN per container:
2 GiB → ~17 (was 10 — brain-jar was saturating)
1 GiB → ~8
512 MiB → ~3 (cap-marginal per the memory note; bump container if
site grows)
Dropped LSAPI_MEM_SOFT/HARD computation in detect-memory: AVAILABLE/CHILDREN
was conflating VSZ with RSS-budget arithmetic and would have killed
legitimate workers. The 1024/1500 hard-coded values in the template
comfortably fit typical Divi/WooCommerce VSZ (280-365 MB).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
82 lines
3.0 KiB
Bash
82 lines
3.0 KiB
Bash
#!/usr/bin/env bash
|
|
## detect-memory-litespeed.sh — sibling to detect-memory.sh.
|
|
## Computes LSAPI_CHILDREN + extprocessor memSoftLimit/memHardLimit from
|
|
## container memory cap. Sourced by entrypoint-litespeed.sh.
|
|
|
|
## ---- container memory detection (mirrors detect-memory.sh) ----
|
|
CONTAINER_MEMORY_BYTES=""
|
|
|
|
if [ -f /sys/fs/cgroup/memory.max ]; then
|
|
val=$(cat /sys/fs/cgroup/memory.max 2>/dev/null)
|
|
if [ "$val" != "max" ] && [ -n "$val" ]; then
|
|
CONTAINER_MEMORY_BYTES=$val
|
|
fi
|
|
fi
|
|
|
|
if [ -z "$CONTAINER_MEMORY_BYTES" ] && [ -f /sys/fs/cgroup/memory/memory.limit_in_bytes ]; then
|
|
val=$(cat /sys/fs/cgroup/memory/memory.limit_in_bytes 2>/dev/null)
|
|
if [ -n "$val" ] && [ "$val" -lt 8589934592000 ] 2>/dev/null; then
|
|
CONTAINER_MEMORY_BYTES=$val
|
|
fi
|
|
fi
|
|
|
|
if [ -z "$CONTAINER_MEMORY_BYTES" ] && [ -f /proc/meminfo ]; then
|
|
mem_kb=$(awk '/^MemTotal:/ {print $2}' /proc/meminfo)
|
|
if [ -n "$mem_kb" ]; then
|
|
CONTAINER_MEMORY_BYTES=$((mem_kb * 1024))
|
|
fi
|
|
fi
|
|
|
|
if [ -z "$CONTAINER_MEMORY_BYTES" ]; then
|
|
CONTAINER_MEMORY_BYTES=$((512 * 1024 * 1024))
|
|
fi
|
|
|
|
CONTAINER_MEMORY_MB=$((CONTAINER_MEMORY_BYTES / 1024 / 1024))
|
|
|
|
## ---- budget split (LSAPI workers get the lion's share) ----
|
|
OS_RESERVE_MB=50
|
|
OLS_RESERVE_MB=40 # OpenLiteSpeed daemon footprint
|
|
DEV_OVERHEAD_MB=0
|
|
if [ "${environment:-PROD}" = "DEV" ]; then
|
|
DEV_OVERHEAD_MB=125
|
|
fi
|
|
|
|
AVAILABLE_MB=$((CONTAINER_MEMORY_MB - OS_RESERVE_MB - OLS_RESERVE_MB - DEV_OVERHEAD_MB))
|
|
if [ "$AVAILABLE_MB" -lt 60 ]; then
|
|
AVAILABLE_MB=60
|
|
fi
|
|
|
|
## ---- LSAPI children (analogous to PHP_FPM_MAX_CHILDREN) ----
|
|
## Per the 2026-06-02 cac-litespeed memory-sizing finding (vantagehealth
|
|
## OOM-spawn loop at 512 MB cap): each lsphp worker carries ~115 MB
|
|
## shmem-rss which is RSS-accounted per worker (vs cac-fpm's COW-shared
|
|
## fork model). Real-world worker budget ≈ 115 MB shmem + ~50-100 MB anon
|
|
## that scales with workload. 115 MB is the safe per-worker estimate for
|
|
## the divisor; floor at 2, cap at 50.
|
|
##
|
|
## Sub-512 MB containers are unsafe for dynamic WP on OLS per the memory
|
|
## note — the floor of 2 workers still applies but it'll be cap-marginal.
|
|
LSPHP_WORKER_ESTIMATE_MB=${LSPHP_WORKER_ESTIMATE_MB:-115}
|
|
|
|
calc_lsapi_children=$((AVAILABLE_MB / LSPHP_WORKER_ESTIMATE_MB))
|
|
if [ "$calc_lsapi_children" -lt 2 ]; then
|
|
calc_lsapi_children=2
|
|
fi
|
|
if [ "$calc_lsapi_children" -gt 50 ]; then
|
|
calc_lsapi_children=50
|
|
fi
|
|
|
|
## Per-site override knobs — site-pool-env.php still passes FPM_MAX_CHILDREN
|
|
## for backward compat, so prefer LSAPI_CHILDREN if set, else FPM_MAX_CHILDREN,
|
|
## else the calculated value.
|
|
LSAPI_CHILDREN=${LSAPI_CHILDREN:-${FPM_MAX_CHILDREN:-$calc_lsapi_children}}
|
|
|
|
## Per-worker mem limits (RLIMIT_AS) live in httpd_config.tpl now as
|
|
## hard-coded 1024M soft / 1500M hard — those values comfortably fit
|
|
## typical Divi/WooCommerce VSZ (~280-365 MB) while still catching a
|
|
## true runaway script. Cgroup remains the real backstop. The earlier
|
|
## AVAILABLE/CHILDREN formula was killing legitimate workers because
|
|
## it conflated VSZ (RLIMIT_AS) with RSS-budget arithmetic.
|
|
|
|
export CONTAINER_MEMORY_MB LSAPI_CHILDREN
|