How to Check VPS Memory Usage Before Upgrading RAM

Low free memory alone does not mean a Linux VPS needs more RAM. Linux uses otherwise idle memory for caches. Look at available memory, active swapping, out-of-memory events and application latency during representative load. Upgrade when those observations show a genuine capacity constraint rather than a misleading percentage.

Collect a read-only snapshot

These commands are for a Linux VPS with procps tools installed, such as common Ubuntu or Debian images. They observe the system; they do not change memory limits or disable services. If a command is absent, use the distribution’s documented package instructions or your monitoring agent.

free -h
vmstat 1 10
ps -eo pid,comm,rss --sort=-rss | head -n 11

Run them while the slow operation is happening and again during normal operation. Record timestamps, workload and the service affected. Keep process listings private when they expose service names or tenant information.

What to read in the output
Signal	Meaning	Caution
free: available	Estimate of memory available to new work without swapping	Not a guarantee that a container has the same allowance
vmstat: si / so	Swap-in and swap-out activity over the interval	Read repeated interval rows; the first row covers time since boot
ps: RSS	Resident memory attributed to a process, typically in KiB here	Shared pages can be counted in more than one process
Application response time	Whether the workload is meeting its goal	A memory graph cannot replace an application-level check

Check the limit that actually applies

A virtual machine may have spare memory while a container or service inside it hits a separate limit. Inspect the application’s configured heap/cache and its container or service allowance. Compare the termination message with the enforcing limit before increasing the whole VM.

For example, suppose a VPS has capacity remaining but one container is configured with a much smaller memory allowance. Increasing the VPS size without changing that container configuration may leave exactly the same failure. Conversely, raising every container limit can overcommit the host if they all become busy together.

What is stronger evidence of memory pressure?

Available memory remains low during normal peak traffic and application latency worsens at the same time.
Repeated swap activity coincides with slow work, rather than merely showing that swap contains some old pages.
The kernel, container runtime or service supervisor records a memory-related termination.
The application’s own metrics show its working set or configured cache is constrained.

Correlated observations narrow the investigation; they do not automatically prove a leak. Growing memory may be intentional caching, a workload change or retained objects that should have been released. Keep longer-term observations and compare comparable traffic periods before selecting a remedy.

Turn observations into a capacity plan

List the OS, application, database and background tasks sharing the VPS. Include deployment overlap and backup jobs in the test window. A quiet one-minute snapshot will not capture those peaks. Choose headroom from the uncertainty and variability of the workload instead of treating a fixed percentage as a universal rule.

If memory is not the constraint, review CPU scheduling, storage and the application itself. The existing VPS sizing guide covers the wider decision. Compare EnderHost VPS allocations after writing down the resource change you expect to help.

Do not clear caches or disable swap solely to make a dashboard look better. Those changes alter system behavior and can make the original measurements less representative.