feat(container): auto-tune JVM GC algorithm in setenv.sh based on available vCPUs

[wezell]

Summary

• Replaces the static JAVA_OPTS_MEMORY GC config with CPU-aware auto-selection at container startup
• 1–3 vCPUs → G1GC (default) + G1PeriodicGCInterval=10000 to return memory to OS on idle
• 4+ vCPUs → -XX:+UseZGC (Java 25 GenerationalZGC by default; sub-millisecond pauses, scales with cores)
• SerialGC explicitly excluded — not appropriate for a long-running multi-threaded web server

Details

CPU detection uses nproc with /proc/cpuinfo fallback; defaults to 2 if neither is available. Base memory flags (MaxRAMPercentage=72.0, heap free ratios, NIO buffer cap) are unchanged. Set JAVA_OPTS_MEMORY before startup to bypass auto-selection entirely.

Follows the same cgroup-aware pattern already used by JAVA_OPTS_DIRECT.

Test plan

• Verify startup log prints setenv: auto-GC: ... with detected vCPU count
• On a 1-vCPU container (or nproc returning 1–3), confirm G1PeriodicGCInterval appears in JVM flags (-XX:+PrintFlagsFinal or jcmd <pid> VM.flags)
• On a 4+-vCPU container, confirm -XX:+UseZGC / GenerationalZGC is active
• Set JAVA_OPTS_MEMORY="-XX:MaxRAMPercentage=60.0" and confirm auto-tune block is skipped
• Confirm no regression in startup time or heap usage on standard containers

Closes #36258

🤖 Generated with Claude Code

[github-actions]

🤖 Bedrock Review — deepseek.v3.2

[🟠 High] dotCMS/src/main/resources/container/tomcat9/bin/setenv.sh:15 — nproc may not be available in all container environments; fallback to /proc/cpuinfo is good, but the echo 2 default could misconfigure high-core systems if both commands fail. This matters because it could force G1GC on large systems, hurting performance.

[🟡 Medium] dotCMS/src/main/resources/container/tomcat9/bin/setenv.sh:19 — Using -XX:+UseZGC assumes Java 25's GenerationalZGC is the default; this is correct for the target Java version, but if the script runs on an older JVM, ZGC may not be available, causing startup failure. This matters for compatibility in mixed environments.

[🟡 Medium] dotCMS/src/main/resources/container/tomcat9/bin/setenv.sh:58 — Renaming DB_MAX_WAIT to DB_MAX_CONNECTION_LIFETIME is a breaking change for existing deployments that set DB_MAX_WAIT as an environment variable. This matters because it could silently change connection pool behavior unless migration documentation is provided.

---

_{Run: #27966042641 · tokens: in: 1078 · out: 261 · total: 1339}

[claude]

Claude finished @wezell's task in 1m 22s —— View job

---

Rollback Safety Analysis

• Gathering context
• Reading rollback-unsafe categories reference
• Analyzing PR diff
• Applying label → AI: Safe To Rollback

---

Result: ✅ Safe to Roll Back

The single changed file (dotCMS/src/main/resources/container/tomcat9/bin/setenv.sh) is a container startup shell script. Checked against every category in the reference:

Category	Verdict
C-1 Structural Data Model Change	✅ Not applicable — no DB, no Java model
C-2 Elasticsearch Mapping Change	✅ Not applicable
C-3 Content JSON Model Version Bump	✅ Not applicable
C-4 DROP TABLE / DROP COLUMN	✅ Not applicable
H-1 One-Way Data Migration	✅ Not applicable
H-2 RENAME TABLE / RENAME COLUMN	✅ Not applicable
H-3 PK Restructuring	✅ Not applicable
H-4 New ContentType Field Type	✅ Not applicable
H-5 Binary Storage Provider Change	✅ Not applicable
H-6 DROP PROCEDURE / DROP FUNCTION	✅ Not applicable
H-7 NOT NULL without default	✅ Not applicable
H-8 VTL Viewtool Contract Change	✅ Not applicable
M-1 Non-Broadening Column Type Change	✅ Not applicable
M-2 Push Publishing Bundle Format Change	✅ Not applicable
M-3 REST / GraphQL API Contract Change	✅ Not applicable
M-4 OSGi Plugin API Breakage	✅ Not applicable

Notes:

• The GC auto-selection logic is purely additive — it replaces a static JAVA_OPTS_MEMORY default with a runtime-computed default. Rolling back to N-1 simply restores the static G1GC line; no state is persisted between versions.
• The DB_MAX_WAIT → DB_MAX_CONNECTION_LIFETIME rename is an env-var default name change, not a DB schema change. Any deployment that relied on DB_MAX_WAIT being set externally would need to rename that env var, but since this is a script default (not a stored value), a rollback simply restores the old default name with no data loss.

[swicken]

I don't see any consumers of the new name