In my previous post, we looked at how default Google guest daemons consume over 15% of available memory on a 1 GB Google Compute Engine (e2-micro) instance, pushing standard Debian images into SSH lockout during moderate memory pressure.

To see how far we could push the lower boundary of GCE instances without sacrificing reliability, I built a custom minimal Alpine Linux image (alpine-3-24-1-uefi-lite-v5).

We subjected this image to a punishing synthetic stress harness: pinning 900 MB to 1,250 MB of memory, driving 16 concurrent worker threads, and executing over 167,000 sub-processes in five minutes. While standard Debian froze solid, the Alpine instance maintained sub-second SSH logins and responsive interactive keystrokes.

Here is the architectural teardown of how this custom image stayed alive under 100% memory saturation.

The Three Architectural Pillars

1. Dropbear over OpenSSH + musl libc

Standard OpenSSH on Debian or Ubuntu relies on GNU glibc and dynamic PAM evaluation. When an SSH connection arrives, sshd spawns a heavyweight process dynamically linked against libpam, libselinux, libcrypto, libsystemd, and libcurl (~25 MB of mappings), requiring hundreds of clean memory pages just to build the page table.

Our Alpine image swaps OpenSSH for Dropbear SSH running atop musl libc:

  • Dropbear Resident Footprint: Spawns in ~800 KB of RAM.
  • Zero Bloated Linkages: Links against only musl libc.so and libcrypt.so.
  • Zero Fork/PAM IPC Stalls: Directly checks static keys in ~/.ssh/authorized_keys with a single filesystem read, requiring fewer than 15 memory pages to authenticate.

2. Stripping the Google Guest Stack

Standard GCE distributions run three to four persistent Go daemons (google_osconfig, google-guest-agent-manager, core_plugin, google_guest_compat_manager), which permanently hold ~155 MB of resident RAM (RSS) hostage.

By eliminating these background services and relying on a lean, one-shot metadata bootstrap at boot time (cloud-lite):

  • Baseline Memory at Idle: Only ~90 MB used out of 968 MB total RAM.
  • Available Headroom: Over 850 MB of raw, unfragmented physical RAM is left entirely to the user workload.

3. zRAM Swap: Microsecond In-Memory Paging

The default storage on GCP Free Tier is network-attached pd-standard persistent disk, offering limited IOPS and zero swap space by default. When physical RAM drops below 20 MB on standard Linux, the kernel purges clean page caches, causing hard disk read deadlocks (processes stuck in uninterruptible sleep D state).

Our Alpine image configures zRAM swap (/dev/zram0) with a 512 MB compressed pool backed by lz4:

  • Zero Disk I/O Wait (0% io): Cold anonymous pages are compressed and stored in an in-memory kernel pool at memory bus speeds (> 4,000 MB/s).
  • Virtual Capacity Expansion: With typical 2.5:1 compression ratios, 400 MB of inactive process data compresses into ~160 MB of physical space, effectively transforming a 968 MB VM into a ~1.3 GB+ machine.

The Stress Harness: Testing to the Breaking Point

To benchmark resilience deterministically, we used a custom, statically compiled Go stress harness (stress_harness) designed to trigger kernel starvation:

  • Heap Anchor: Deterministically commits physical RSS by writing across 4 KB pages.
  • Process Storm: Spawns 16 worker goroutines executing ephemeral sub-processes (/bin/true) in tight loops.
  • VFS Cache Sweeps: Continuously creates, walks (filepath.Walk), and unlinks 5,000 to 10,000 nested files in /tmp.
  • Integrated SSH Canary: Concurrently dials port 22 every 1 second, asserting connection and banner exchange latency.
               +-------------------------------------------------------------+
               |                  Synthetic Stress Engine                    |
               +-------------------------------------------------------------+
                                       |
        +------------------+-----------+-----------+------------------+
        |                  |                       |                  |
        v                  v                       v                  v
+---------------+  +---------------+       +---------------+  +---------------+
| Process Churn |  | Inode / Cache |       | Memory Anchor |  | Socket Churn  |
|  (16 Workers) |  | (5,000 Files) |       | (700-1250 MB) |  |  (Localhost)  |
+---------------+  +---------------+       +---------------+  +---------------+

Benchmark Results across Pressure Levels

Run 1: The 700 MB Anchor (Moderate Squeeze)

  • Parameters: -mem-anchor-mb 700 -concurrency 16 -duration 60s
  • Processes Executed: 104,069 in 62 seconds (~1,660 execs/sec)
  • Memory Status: 700 MB pinned, ~150 MB zRAM swap used.
  • SSH Canary Result: 0 timeouts. Maximum Dropbear handshake latency was 1.50 seconds. Keystroke echo was instantaneous.

Run 2: The 900 MB Anchor (Extreme Squeeze)

  • Parameters: -mem-anchor-mb 900 -concurrency 16 -timeout 300
  • Processes Executed: 167,684 processes in 300 seconds.
  • Files Walked / Purged: 130,000 files.
  • Memory Status:
    • Physical RAM: 868 MB used (only 15 MB available).
    • zRAM Swap: 429 MB active out of 512 MB.
    • Process Virtual Size (VSZ): 2,395 MB (247% of physical RAM).
  • SSH Responsiveness: Keystroke latency settled at a stable, bounded ~250 ms due to CPU scheduler queueing, but zero dropped connections or timeouts. Disconnecting and reconnecting SSH was instantaneous.

Run 3: The 1,250 MB Absolute Boundary

  • Parameters: -mem-anchor-mb 1250 -concurrency 16
  • Result: Saturated 100% of physical RAM (0 MB available) and 100% of zRAM swap (512 MB full).
  • The Limit: At this point, with zero physical pages and zero compressed swap buffers remaining, new process fork() calls blocked, demonstrating the absolute ceiling before hypervisor CPU credit exhaustion and memory saturation halted incoming connection banners.

Conclusion

Small VMs don’t have to be fragile. The chronic unresponsiveness and SSH timeouts that developers encounter on 1 GB cloud instances are not inherent hardware limitations—they are the byproduct of standard distribution bloat, heavy cloud management agents, and missing swap strategies.

By combining:

  1. Dropbear SSH for tiny fork footprints,
  2. Lean boot metadata instead of persistent background daemons, and
  3. zRAM swap to absorb transient allocation spikes at memory speeds,

we engineered an e2-micro instance that casually absorbed a 2.4 GB virtual memory workload without dropping an administrator out of their terminal.