# A 512MB VPS OOM Incident: SSH Closed Instantly, API 521, and the Low-Memory Cleanup Afterward Source: https://blog.ferstar.org/en/posts/vps-low-memory-oom-ssh-api-recovery/ > I am not a native English speaker; this article was translated by AI. This was not a migration. It was what happened after the migration, when a small VPS finally pushed back. The symptoms looked like a network issue: the local SSH alias closed instantly, the provider web console got stuck at "connecting", and the API behind Cloudflare turned into a 521. The awkward part was that the proxy service on the same host still worked, so it was not a complete host failure. It also did not fit the usual suspects: floating IP, local TUN proxy, or SSH key problems. After a reboot, SSH came back and I could inspect the machine. The conclusion was clear: 512MB RAM was too tight, and the system had hit repeated page allocation failures in the network receive path. Nginx stream, SSH, and the API entrypoint were all dragged into a half-broken state. ## Symptoms SSH failed before key authentication: ```text kex_exchange_identification: Connection closed by remote host ``` That detail mattered. The connection had reached the remote side, but SSH never got to normal authentication. So this was not a changed key, bad file permission, or dirty `known_hosts`. The entrypoint design on this host is slightly indirect: ```mermaid flowchart LR Client["client"] Nginx["nginx stream :443"] SSH["sshd :22"] API["api backend :8000"] FM["filebrowser"] CF["Cloudflare"] Client -->|SSH over 443| Nginx CF -->|api.example.com| Nginx CF -->|fm.example.com| Nginx Nginx -->|default stream| SSH Nginx -->|SNI api| API Nginx -->|SNI fm| FM ``` SSH, the API, and the file service all pass through Nginx stream. If Nginx, the kernel network stack, or local memory pressure goes sideways, the outside world sees it as "SSH is down" and "the API is down" at the same time. ## The real evidence After the reboot, the useful kernel log keyword was not `sshd`. It was this: ```bash journalctl -k --since "2026-06-13 00:00:00" | \ egrep -i "page allocation failure|out of memory|oom|killed process" ``` Before the reboot, there had been repeated `page allocation failure` messages involving processes like: - `containerd-shim` - `containerd` - `dockerd` - `hysteria` - `runc` - `kswapd0` The stack traces were concentrated in the receive path, with functions like `virtio_net`, `tcp_gro_receive`, and `skb_page_frag_refill`. So this was not just one application writing too many logs. Low memory had already started affecting how the kernel handled network packets. That also explains why the failure looked so strange. A TCP port might still accept connections, and a UDP proxy might still appear alive, while SSH handshakes, Nginx stream forwarding, and API upstream traffic fail randomly under memory pressure. ## Round one: clean up the system and kernel First, I put the package and kernel state back into something predictable. The XanMod source was still using the old form: ```bash deb [signed-by=/etc/apt/keyrings/xanmod-archive-keyring.gpg] http://deb.xanmod.org releases main ``` For Debian 13, I changed it to the codename-based source: ```bash deb [signed-by=/etc/apt/keyrings/xanmod-archive-keyring.gpg] http://deb.xanmod.org trixie main ``` Then I installed the current x64v3 XanMod kernel: ```bash apt update apt install linux-xanmod-x64v3 reboot ``` After reboot: ```bash uname -r # 7.0.12-x64v3-xanmod1 ``` Old kernels were removed as well, leaving only the current XanMod packages and avoiding stale boot entries: ```bash apt autoremove --purge apt clean update-grub ``` I also cleaned journald and unused Docker objects: ```bash journalctl --vacuum-time=7d docker system prune -af ``` This did not remove Docker volumes. Business data should not be part of a cleanup shortcut. ## Round two: give 512MB RAM a fallback path The machine has only about 454MiB of usable RAM. "Hope the applications behave" is not an operating model. The system needs defined escape routes when memory gets tight. ### Expand swap I expanded swap to 2GB: ```bash swapoff /swapfile fallocate -l 2G /swapfile chmod 600 /swapfile mkswap /swapfile swapon /swapfile ``` `/etc/fstab` stays simple: ```fstab /swapfile none swap sw 0 0 ``` ### Change zswap to zstd zswap was already enabled, but its default compressor was `lzo`. I checked that the kernel supported zstd: ```bash grep -i zstd /proc/crypto grep CONFIG_CRYPTO_ZSTD /boot/config-$(uname -r) ``` Runtime switch: ```bash echo zstd > /sys/module/zswap/parameters/compressor cat /sys/module/zswap/parameters/compressor # zstd ``` Then I made it persistent in GRUB: ```bash GRUB_CMDLINE_LINUX_DEFAULT="zswap.enabled=1 zswap.compressor=zstd net.ifnames=0 biosdevname=0" update-grub ``` ### Leave some room for network and memory pressure I added `/etc/sysctl.d/99-lowmem-network-tuning.conf`: ```conf vm.min_free_kbytes = 16384 vm.swappiness = 30 vm.vfs_cache_pressure = 100 net.core.netdev_max_backlog = 2500 ``` I had tried a higher `vm.min_free_kbytes` first, but on a 512MB host it was too aggressive and squeezed user-space memory. Around 16MB is closer to what this machine can tolerate. ## Round three: decide what should die first The worst low-memory behavior is everyone fighting for memory until the kernel randomly kills something critical. I wanted the priorities to be explicit. ### Protect entrypoint services I added a systemd drop-in for `ssh`, `nginx`, and `supervisor`: ```ini [Service] OOMScoreAdjust=-700 ``` In practice, `sshd` was already at `-1000`, while Nginx, Supervisor, and gunicorn were at `-700`: ```bash for pid in $(pgrep -f "sshd|nginx|supervisord|gunicorn"); do printf "%s score=%s adj=%s cmd=%s\n" \ "$pid" \ "$(cat /proc/$pid/oom_score)" \ "$(cat /proc/$pid/oom_score_adj)" \ "$(tr '\0' ' '