Give memory spikes a bounded safety margin
Recent kernel records showed OOM kills while the host had no active swap. A persistent 4 GiB swap area is now active, and the affected model container has bounded swap headroom without raising its RAM cap.
Change and evidence
The host now has an active persistent swap unit. Linux is configured to favor RAM during normal operation, while swap remains available when memory is tight. The target container retains its 4 GiB RAM limit; only its combined memory-plus-swap allowance increased to 8 GiB.
Verification confirmed that Docker, the OERSI autonomy loop and the encrypted backup timer remained active. Available root-disk space is approximately 41 GiB after reserving the swap file, still above the backup job's 25 GiB preflight guard.
Read the Markdown report · Machine-readable audit · Public API record
Verification boundary
Swap is not equivalent to physical RAM. Heavy swapping can slow model inference, and a workload with a large active working set can still hit its 4 GiB container RAM cap. The host's 4 GiB swap pool is shared across all services. This report records a resilience improvement, not a claim that OOM risks have been eliminated.
The modified swap allowance is stored on the existing Docker container. If it is later removed and recreated, its launch configuration must keep the same allowance. No container restart, application deployment or model-weight change was part of this operation.
Raw logs, private credentials, internal container IDs and private configuration values are not published.