How Much RAM Does a Small VPS Need? Measure Before You Upgrade
A small website can run comfortably on a modest VPS—or run out of memory when the database, application and a scheduled task peak together. The right size depends on your software and workload. One quiet reading, or a plan's headline RAM figure, cannot tell you the answer.
This guide shows how to collect a few read-only observations on a Linux VPS. It does not change memory limits, stop services or create swap. The sample numbers are illustrative, not measurements or a sizing recommendation. On a narrow screen, scroll long code blocks sideways to see the full line.
1. Record memory at several useful moments
On the VPS itself, run:
free -h
For example, a hypothetical quiet-period result using the current procps definition of used might look like this:
total used free shared buff/cache available
Mem: 1.9Gi 1.3Gi 120Mi 20Mi 700Mi 620Mi
Swap: 1.0Gi 100Mi 924Mi
The small free number alone does not mean the server is nearly out of memory: Linux also uses memory for cache. The available column estimates how much memory can be made available for new applications without swapping; it is an estimate, not a guarantee. Columns and the calculation of used can vary between versions of free, so compare observations from the same system. Swap usage shows that some swap is occupied, but a single snapshot does not tell you when it was used or whether active swapping is slowing the server. Swap can provide a buffer; disk-backed swap is generally slower than RAM.
Record the time, available RAM and swap usage during normal use, a busy period and an ordinary scheduled job such as a backup or build. Use existing activity; do not create artificial load on a live customer service. For a representative peak, a few manual samples can miss short spikes: use existing monitoring if available, or repeat observations without assuming you have measured the true peak.
2. Find where to investigate
ps -eo pid,rss,comm --sort=-rss | head -n 11
This lists up to ten visible processes with the highest resident memory after the header; RSS is shown in KiB. Look for the application, database, web server and background workers. It is a point-in-time view: process RSS can include shared memory, so adding rows does not reliably give total host usage. Permissions, process visibility and available options vary by system. Process names may reveal information about your setup; review output before sharing it.
If the service runs in Docker, you have authorized access, and you have checked that your current Docker context points to the intended daemon:
docker stats --no-stream
This reports one sample for running containers, including displayed memory usage and limit. On Linux, Docker's CLI subtracts a cache component from the displayed usage; host memory, the Docker API and container figures can therefore differ. Do not add container values to the host's used memory: that would count some usage twice. free run inside a container can report host-level figures rather than the container's effective limit. Limits and accounting depend on the runtime, cgroup version, configuration and kernel support. Docker access may require elevated privileges; use your normal authorized account rather than changing permissions for this check. Review container names and other details before sharing the output.
If a container has stopped and you know its name or ID, you can inspect its current recorded state:
docker inspect --type=container --format '{{.State.OOMKilled}}' CONTAINER_NAME_OR_ID
Replace CONTAINER_NAME_OR_ID with the relevant name or ID. true is a useful lead; false does not rule out an earlier memory event, a different container or a host-level problem. It is not a complete incident history. Check your monitoring and relevant logs as well, with appropriate access and care around sensitive data. A missing Docker command or permission error simply means this check was not available in your environment.
3. Turn observations into a buying decision
For each observation, note the time, available RAM and swap used, along with the workload:
- Normal traffic: were the application and database running?
- Busy period: approximately how many users or jobs, if known?
- Scheduled task: was a build, backup or import running, and for how long?
- Incident: when did it happen, and is there relevant restart or OOM evidence?
If available RAM repeatedly becomes very low during representative activity, or you have confirmed memory-related failures, examine the processes, container limits and workload first. Then compare the current plan with a larger configuration and its full renewal cost. Reducing unnecessary services or changing application settings may help, but an isolated test is safer than making changes during an incident. Do not disable the OOM killer as a shortcut.
Before ordering, check whether the chosen region offers the desired RAM, CPU, disk and operating-system image; how resizing works; whether resizing requires a restart; and the price and billing period shown at checkout. Leave room for the operating system, updates and ordinary workload variation. Neither an average reading nor a universal percentage can guarantee enough capacity for every application.
Sources and disclosure
- Linux kernel: /proc/meminfo and MemAvailable
- Linux free manual
- Docker: resource constraints and out-of-memory risks
- Docker: container stats and Linux memory accounting
Disclosure: This guide was prepared for UCELI, a cloud server provider, with AI assistance. Examples are hypothetical; verify commands and behavior against your own operating system and software versions. You can explore UCELI Cloud Server regions and configurations; availability and prices depend on your selection. For pre-sales questions, contact support@uceli.com.
Comments
Post a Comment