Downsizing a Linux VM? Check Memory Headroom First

Suppose your application VM looks quiet during the day, and you’re considering less RAM to reduce its cost. The awkward detail is a nightly import that shares the same machine. Before downsizing, measure memory headroom during that busy window and compare it with application performance. A quiet dashboard reading cannot establish that the smaller VM will cope.

This guide is for a self-managed Linux guest, including a workload you operate on Cube. It helps you decide what to measure before a sizing change; it doesn’t prescribe a resize command or a universal amount of spare RAM. The import is a hypothetical example, and the commands below are read-only examples that weren’t executed for this article.

Start inside the guest with the procps tools available on your distribution:

free -h
vmstat 1 10

Read available in free as an estimate of memory that can support new applications without swapping. It differs from free, which describes unused memory. The free manual explains that the estimate accounts for page cache and the fact that some reclaimable memory remains in use. Keep the tool version and units with your notes; a dashboard’s “used” metric may use a different definition.

That distinction cuts both ways. Little completely unused RAM doesn’t automatically mean the VM is too small. Plenty of available memory at lunchtime doesn’t establish headroom during tonight’s import. The reading describes the machine when you sampled it. For a sizing decision, you need observations that include the work you’re paying the machine to handle.

In vmstat, swpd is the amount of swap in use, while si and so report swap activity per second. Its first report includes rates averaged since boot; later reports cover the sampling interval, while process and memory fields are instantaneous. See the vmstat manual before comparing the first row with the next nine.

Ten updates are enough to learn the layout, not enough to characterize a nightly workload. Used swap alone doesn’t tell you whether the system is swapping actively now. Repeated swap activity alongside worsening request latency or a longer import is a reason to investigate before removing RAM. Zero swap activity also needs context: check whether swap exists, and don’t treat a machine with no swap as proof that memory pressure is absent.

Where the kernel exposes Pressure Stall Information, add another observation:

cat /proc/pressure/memory

The kernel’s PSI documentation describes some as time when at least some tasks are stalled on the resource, and full as time when all non-idle tasks are stalled together. The averages cover 10, 60 and 300 seconds. This measures lost progress, which makes it useful alongside capacity readings. If the file is unavailable, record that gap rather than interpreting it as zero pressure.

For the hypothetical import, keep a timeline through startup, its busiest phase and completion. Use existing monitoring or an approved collection method to retain available memory, swap activity, pressure when available, job duration, request latency and errors. Record input size, worker concurrency and the application version too. Repeat across the workload’s meaningful cycles; a weekday sample may miss a weekly report or month-end batch.

Here’s a useful decision note to write before changing anything: “We are considering less guest RAM. The observations include these workload peaks. These are the latency, completion-time and error limits we must preserve. This is how we will restore the previous configuration if the trial fails.” Fill it with your own evidence. If you cannot name the peak or the recovery path, defer the change and collect what’s missing.

Be careful with a tempting shortcut: subtracting one observed available value from total RAM and buying exactly that remainder. It turns an estimate at one moment into a capacity guarantee. It also ignores how the workload may respond to a smaller cache. The kernel’s memory concepts guide explains that page cache avoids repeated file reads from storage. Reclaimable memory can still be useful to performance.

A practical approach is a controlled comparison: use a representative copy or another suitable environment first, keep input and concurrency comparable, and change one resource dimension at a time. Confirm the provider’s supported change procedure, backup requirements and recovery options before an actual change. Don’t flush caches or disable swap merely to make the baseline look cleaner. Include both startup and steady operation, since the trial should resemble how the service will run.

If the smaller environment meets the application’s limits through the important workload phases, you have evidence for that configuration under those conditions. If latency grows, the import overruns its window, pressure rises materially or errors appear, pause the cost change and investigate. A successful trial still doesn’t predict every future traffic burst, so retain monitoring and review the decision as the workload changes.

Keep container limits separate from guest capacity. A container can hit its own ceiling even while the guest has headroom. If you’re investigating a killed Docker process rather than planning a downsizing trial, use the exit code 137 diagnosis to establish what happened before changing memory.

For a new workload, Cube offers a Linux microVM with selectable CPU, RAM and disk. Choose resources from your workload evidence and check the current product and billing details before committing. This article makes no claim that a smaller configuration saves a particular percentage, or that guest readings expose the underlying physical host’s capacity.

Your next action can be small: identify the next busy workload window, retain its memory and application observations, and write the decision note. That gives you something firmer to act on than an idle machine’s green chart.

Creation context: this AI-assisted guide uses the linked primary documentation. The scenario is hypothetical, no workload benchmark was performed for this article, and the cover is a generated conceptual illustration.