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>
97 lines
4.2 KiB
Smarty
97 lines
4.2 KiB
Smarty
## OpenLiteSpeed APPEND fragment — added to the stock httpd_config.conf
|
|
## that ships with litespeedtech/openlitespeed. Keeping the stock config
|
|
## intact preserves all the cgid/lscgid plumbing (CGIRLimit defaults,
|
|
## fileAccessControl defaults, etc.) — when we tried writing a fully
|
|
## custom httpd_config.conf, lscgid never created its IPC socket and
|
|
## every PHP request 503'd. The upstream OLS docker template uses this
|
|
## append pattern too (see setup_docker.sh in litespeedtech/ols-dockerfiles).
|
|
##
|
|
## Rendered at container start by scripts/create-vhost-litespeed.sh via
|
|
## envsubst. Templated vars: $user $domain $vhost_map_aliases $PHPVER
|
|
## $LSAPI_CHILDREN (computed by detect-memory-litespeed.sh)
|
|
|
|
## --- our listeners (replace stock Default :8088) ---
|
|
listener HTTP {
|
|
address *:80
|
|
secure 0
|
|
map siteVH *
|
|
## NB: HTTP→HTTPS redirect is in site-template.tpl's rewrite{} block,
|
|
## NOT here — OLS 1.8 listener-level rewrites are inert for vhTemplate
|
|
## members. Don't move it back to this listener.
|
|
}
|
|
|
|
listener HTTPS {
|
|
address *:443
|
|
secure 1
|
|
keyFile /usr/local/lsws/conf/cert/self.key
|
|
certFile /usr/local/lsws/conf/cert/self.crt
|
|
sslProtocol 24
|
|
enableSpdy 15
|
|
enableQuic 0
|
|
map siteVH *
|
|
}
|
|
|
|
## --- lsphp extProcessor (overrides the stock one which is hard-coded to
|
|
## PHP_LSAPI_CHILDREN=10 regardless of container memory).
|
|
##
|
|
## Sized dynamically by detect-memory-litespeed.sh based on the cgroup cap:
|
|
## 2 GiB container → LSAPI_CHILDREN ≈ 17 (was stuck at 10)
|
|
## 1 GiB container → LSAPI_CHILDREN ≈ 8
|
|
## 512 MiB → LSAPI_CHILDREN ≈ 3
|
|
##
|
|
## Idle-reduction knobs (the question that motivated this whole block):
|
|
## LSAPI_MAX_IDLE_CHILDREN=2 default was CHILDREN/2 (so 10/2=5)
|
|
## LSAPI_MAX_IDLE=60 default was 300 (5 min)
|
|
## Together: max 2 idle workers kept alive, anything idle >60s gets reaped.
|
|
## Trade-off: cold-start of an extra worker after idle reaping costs ~50-100ms
|
|
## on the first request to it. Worth it for shadowdao-sized low-traffic sites
|
|
## where the difference is "30 MB idle" vs "200 MB idle".
|
|
##
|
|
## memSoftLimit/memHardLimit: per-worker RLIMIT_AS catches a runaway PHP
|
|
## script before it hogs the whole pool's memory. Cgroup is still the host
|
|
## backstop (one-customer-per-container), but the per-worker cap protects
|
|
## the OTHER workers in the same pool from a bad-actor script. 1024M soft
|
|
## comfortably accommodates typical Divi/WooCommerce VSZ (~280-365 MB).
|
|
extProcessor lsphp {
|
|
type lsapi
|
|
address uds://tmp/lshttpd/lsphp.sock
|
|
maxConns ${LSAPI_CHILDREN}
|
|
env PHP_LSAPI_CHILDREN=${LSAPI_CHILDREN}
|
|
env LSAPI_MAX_IDLE_CHILDREN=2
|
|
env LSAPI_MAX_IDLE=60
|
|
env PHP_LSAPI_MAX_REQUESTS=500
|
|
env LSAPI_AVOID_FORK=200M
|
|
initTimeout 60
|
|
retryTimeout 0
|
|
persistConn 1
|
|
pcKeepAliveTimeout 30
|
|
respBuffer 0
|
|
autoStart 1
|
|
path /usr/local/lsws/lsphp${PHPVER}/bin/lsphp
|
|
backlog 100
|
|
instances 1
|
|
runOnStartUp 1
|
|
priority 0
|
|
memSoftLimit 1024M
|
|
memHardLimit 1500M
|
|
procSoftLimit 400
|
|
procHardLimit 500
|
|
}
|
|
|
|
## --- our vhost via vhTemplate (upstream's working pattern) ---
|
|
## The template file is /usr/local/lsws/conf/templates/site.conf — written
|
|
## by create-vhost-litespeed.sh at the same time as this fragment.
|
|
vhTemplate site {
|
|
templateFile conf/templates/site.conf
|
|
listeners HTTP, HTTPS
|
|
note cac-litespeed per-customer vhost
|
|
|
|
## vhDomain: customer's domain + serveralias list + `*` catchall so
|
|
## ip-only requests (e.g. HAProxy backend health check by container_name)
|
|
## still resolve. WHP/HAProxy filters hostnames upstream — no risk to
|
|
## allowing the catchall here.
|
|
member siteVH {
|
|
vhDomain ${domain}${vhost_map_aliases}, *
|
|
}
|
|
}
|