Every application running on your VPS needs to keep its working data somewhere close. RAM — Random Access Memory — is that somewhere. It is orders of magnitude faster than any storage device, even NVMe drives, and it is the resource your OS kernel uses to hold everything that is actively in use: application code, database buffers, filesystem caches, and process stacks. When RAM runs short, performance does not degrade gracefully — it collapses.

In a virtual private server environment, memory allocation is more nuanced than the headline figure on a plan specification suggests. The hypervisor platform — KVM, Xen, VMware ESXi, or OpenVZ — determines whether that memory is genuinely reserved for your virtual machine, whether the host can reclaim it under pressure, and how the kernel manages the boundary between guest and host memory. Understanding these distinctions prevents the most common and costly VPS sizing mistakes.

What VPS RAM Actually Does

RAM is volatile, high-speed storage sitting directly on the memory bus. Access latency is measured in nanoseconds — typically 60–100 ns for a DRAM read. Compare that to an NVMe SSD, which delivers sequential read latency of roughly 20–100 microseconds — 200 to 1,000 times slower. For workloads that repeatedly touch the same data (which is nearly all workloads), keeping that data in RAM rather than repeatedly fetching it from storage is the single largest performance lever available.

The Linux kernel manages RAM through a virtual memory subsystem that divides physical memory into 4 KB pages and tracks which pages are in use, which are cached, and which are free. When a process requests memory, the kernel allocates pages from the free pool. When free pages run low, the kernel begins reclaiming memory — first by flushing clean filesystem cache pages (which can be recovered from storage if needed), then by swapping dirty pages to disk, and finally, if memory is exhausted, by invoking the OOM killer.

The three memory zones that matter for your VPS

Application working set. The memory actively used by your running processes — the heap of your application runtime, database buffer pools, in-memory caches, and process stacks. This is the memory you must have available as guaranteed physical RAM. If the working set exceeds available RAM, the kernel begins swapping, and performance becomes unpredictable.

Filesystem page cache. The kernel uses all free RAM not consumed by application working sets as a cache for recently accessed filesystem data. This cache is transparent to applications — reads from cached files complete at near-RAM speed rather than storage speed. The kernel evicts cache pages as needed to make room for application allocations. On a well-sized VPS, the page cache absorbs a significant fraction of filesystem read traffic, dramatically reducing effective storage I/O load on NVMe drives.

Kernel and overhead. The kernel itself consumes memory for its own data structures — page tables, slab allocations, network socket buffers, and loaded modules. On a modern Linux VPS, kernel overhead is typically 100–300 MB depending on workload type and kernel configuration. This overhead is non-negotiable and must be factored into RAM sizing before application allocations.

How RAM Allocation Works Across VPS Platforms

The mechanism by which a VPS provider delivers memory to your virtual machine differs fundamentally between full-virtualisation platforms and container-based platforms. The distinction determines whether your RAM allocation is a hard guarantee or a soft limit.

KVM: hardware-enforced memory isolation

On KVM-based VPS hosting, each virtual machine is allocated memory pages by the host kernel’s KVM subsystem. The virtual machine sees a contiguous block of guest-physical memory that maps onto host-physical pages through Intel EPT (Extended Page Tables) or AMD Nested Page Tables. The crucial question is whether those host-physical pages are committed at VM start or allocated lazily.

Providers who offer reserved or guaranteed memory commit host-physical pages to your VM at boot and will not reclaim them even if the guest is idle. Your VPS has that RAM available regardless of what other tenants on the host are doing. Providers who allow memory overcommit may start your VM with pages committed but later use KVM balloon drivers — a lightweight driver running inside the guest that the host can instruct to “inflate,” claiming guest-visible pages and returning them to the host pool. If the balloon inflates significantly, your effective available memory shrinks below your plan specification without any visible notification in your guest.

To check whether ballooning is active on your KVM VPS, run lsmod | grep virtio_balloon. The presence of that module does not mean ballooning is actively occurring, but it confirms the mechanism is in place. Cross-reference with free -h output — if total available RAM is consistently below your plan’s stated allocation, ballooning or memory overcommit is likely in effect.

Xen: domain memory allocation and balloon driver

Xen manages memory through its Domain memory allocator, which assigns a fixed memory allocation to each DomU (tenant domain) at boot. Xen has historically used balloon drivers in a similar manner to KVM — Dom0 can request a DomU to release memory back to the Xen memory pool. On Xen HVM, memory management is functionally equivalent to KVM from the tenant’s perspective: the guest OS sees a fixed block of guest-physical memory backed by host pages.

Xen’s memory handling on paravirtualised (PV) guests differs slightly — the guest kernel is aware of the Xen hypervisor and participates more directly in memory management through Xen-specific hypercalls. This awareness allows more efficient memory operations but does not change the fundamental question of whether pages are committed or overcommitted by the provider.

VMware ESXi: advanced memory management features

VMware ESXi has the most sophisticated memory management of any major hypervisor platform. It uses four distinct techniques to manage host memory under pressure: transparent page sharing (TPS), which deduplicates identical memory pages across VMs; memory ballooning via the VMware Tools balloon driver; memory compression, which compresses infrequently accessed pages rather than swapping them; and host-level swap (swap-to-disk as a last resort). In enterprise environments running ESXi at controlled overcommit ratios with memory reservation policies, these mechanisms enable high VM density with acceptable performance. For VPS hosting, the practical concern is the same as with KVM and Xen: verify whether your plan includes a memory reservation or operates under an overcommit model.

OpenVZ: cgroup-based memory limits

OpenVZ enforces memory limits through Linux cgroups rather than hardware virtualisation. Each container has a cgroup memory limit — when the container’s memory usage reaches this limit, the kernel begins reclaiming memory within the container’s cgroup namespace. The container does not have visibility into host-level memory — it cannot consume memory outside its cgroup limit, and the host kernel enforces this boundary in software.

A key difference from KVM: on OpenVZ, there is no balloon driver to reclaim memory below your stated allocation. The cgroup limit is the ceiling, and the container can use up to that limit — but the actual physical pages backing that memory are not necessarily committed until used, because the host kernel allocates pages lazily. This means OpenVZ providers can legitimately overcommit physical RAM across containers as long as the aggregate working set across all containers does not exceed host physical RAM. In practice, this means performance on OpenVZ can degrade during periods of host-wide memory pressure in ways that are invisible from within your container.

Guaranteed vs. Burstable RAM: What the Labels Mean

VPS plans increasingly distinguish between guaranteed, burstable, and shared memory allocations. Understanding what each term means in practice is essential to sizing correctly.

The relationship between RAM type and burstable vCPU allocation is worth noting: providers who offer burstable CPU plans typically pair them with overcommitted or burstable memory allocations, since both reflect the same underlying infrastructure model — selling peak capacity as baseline specification and relying on statistical multiplexing across tenants. If your workload has consistent CPU and memory demand rather than bursty patterns, verify that both your vCPU and RAM allocations are reserved rather than burstable.

RAM and the VPS Kernel: Memory Management in Practice

The way the OS kernel manages RAM inside your VPS determines how gracefully (or ungracefully) your server handles memory pressure. Several kernel-level mechanisms directly affect the experience of running close to your memory ceiling.

Swap: the slow safety net

When physical RAM is exhausted, the kernel begins writing inactive memory pages to swap space — an area of storage (typically a dedicated partition or swap file) that acts as an overflow buffer. Swap provides a last-resort safety net that prevents immediate OOM kills, but at severe performance cost: even on fast NVMe drives, swap access is 1,000–10,000 times slower than RAM. Applications that swap actively — a condition called swap thrashing — become nearly unresponsive.

The kernel parameter vm.swappiness controls how aggressively the kernel moves pages to swap before running out of RAM. The default value is 60 on most distributions, meaning the kernel starts swapping well before RAM is fully exhausted. For database workloads and application servers, reducing swappiness to 10 or even 1 delays swap use, keeping more data in RAM at the cost of more aggressive page cache eviction. Set it with sysctl -w vm.swappiness=10 and persist it in /etc/sysctl.d/. Note that this tuning is only available on KVM-based VPS plans where you control your own kernel parameters — on OpenVZ, sysctl parameters affecting global kernel behaviour are set at the host level.

The OOM killer

When both RAM and swap are exhausted, the Linux OOM (Out of Memory) killer activates. It selects a process to terminate based on an OOM score — a heuristic that favours killing large, long-running processes over critical system processes. In practice, the OOM killer often terminates your primary application (the database server, the application runtime) rather than less important background processes, because those tend to be the largest memory consumers by design.

OOM kills are logged in the kernel message buffer — check with dmesg | grep -i oom or journalctl -k | grep -i "out of memory". If OOM events appear in your logs, the correct response is more RAM, not swap — swap only delays the kill under sustained memory pressure.

You can influence which processes the OOM killer protects by adjusting their oom_score_adj value. Setting /proc//oom_score_adj to -1000 makes a process immune to OOM killing. This is useful for protecting critical services like SSH, which you need to maintain access to the server even during a memory crisis.

Transparent Huge Pages

By default, Linux uses 4 KB memory pages. Transparent Huge Pages (THP) allows the kernel to automatically use 2 MB pages for large allocations, reducing the overhead of page table management and TLB misses — particularly beneficial for memory-intensive workloads like databases and in-memory caches. However, THP can also cause latency spikes during page promotion and demotion events, which is why many database vendors (MongoDB, Redis, PostgreSQL) recommend disabling it. Check THP status with cat /sys/kernel/mm/transparent_hugepage/enabled and disable if required with echo never > /sys/kernel/mm/transparent_hugepage/enabled. This setting is configurable on KVM guest kernels.

Sizing RAM for Common VPS Workloads

RAM requirements vary dramatically by workload type. The following sizing guidance is based on realistic working set requirements — accounting for the application itself, its dependencies, the OS and kernel overhead, and a safety margin for traffic spikes and memory fragmentation.

A consistent rule across all workload types: leave 20–30% headroom above your measured peak working set. Memory usage is rarely constant — traffic spikes, batch jobs, and log rotation all create transient demand above the baseline. A VPS running at 95% memory utilisation during normal operation will OOM during the next traffic spike. Size for peak plus margin, not for average.

How to measure your actual memory usage

The most useful command for understanding real memory consumption on a Linux VPS is not top or htop — it is free -h combined with /proc/meminfo. The output of free -h shows total, used, free, shared, buff/cache, and available memory. The “available” figure is the one that matters for capacity planning: it estimates how much memory can be allocated to new processes without swapping, accounting for reclaimable cache. A healthy VPS keeps available memory above 20% of total RAM during peak load.

For per-process memory accounting, ps aux --sort=-%mem | head -20 shows the top memory consumers by RSS (Resident Set Size — the actual physical RAM used). For a more accurate picture of shared memory accounting, smem -r -k | head -20 shows PSS (Proportional Set Size), which distributes shared library memory across processes proportionally. PSS is the most accurate measure of per-process memory cost when shared libraries are a significant factor.

RAM Across the CPU Allocation Stack

Memory and CPU are not independent resources on a VPS — they interact in ways that affect both sizing decisions and performance tuning choices.

RAM and CPU core count

Multi-threaded workloads that scale across CPU cores often have proportional memory requirements. A database server running 8 parallel query workers needs 8 times the per-worker buffer allocation compared to a single-threaded configuration. An application server running 4 Gunicorn workers needs 4 times the per-process heap. When adding CPU cores to handle higher concurrency, always re-evaluate whether the RAM allocation scales proportionally — adding cores without adding memory often creates a new bottleneck at the memory layer.

RAM and dedicated vs. shared vCPU

The relationship between memory allocation type and dedicated vCPU versus shared vCPU plans reflects the same underlying infrastructure philosophy. Plans with dedicated vCPUs typically pair them with reserved RAM — the provider has committed physical resources exclusively to your virtual machine. Plans with shared vCPUs more commonly use overcommitted memory models, since both resources are being shared across tenants in a statistical multiplexing model.

For latency-sensitive applications where both CPU scheduling jitter and memory availability affect response time consistency — API servers, real-time processing pipelines, low-latency trading systems — the combination of dedicated vCPU with reserved RAM eliminates both sources of resource contention simultaneously. For development environments, staging servers, and batch processing workloads, burstable vCPU with standard memory allocation is typically adequate and significantly more cost-effective.

Storage and RAM: The Cache Relationship

RAM and storage performance are tightly coupled on a VPS. The Linux page cache converts what would be storage I/O operations into RAM reads — a difference of several orders of magnitude in latency. Understanding how much of your I/O workload the page cache can absorb determines whether adding RAM or upgrading storage delivers greater performance improvement.

The key metric is the cache hit rate: what fraction of filesystem read operations are served from the page cache rather than physical storage. On a VPS running a read-heavy application with a dataset that fits within available RAM, the page cache hit rate can reach 95–99%, making NVMe drive throughput largely irrelevant for that workload. On a VPS with insufficient RAM to cache its working dataset, I/O wait dominates and even the fastest NVMe storage becomes a bottleneck.

Monitor cache effectiveness with vmstat 1 — watch the si (swap in) and so (swap out) columns. Non-zero values indicate active swapping and an immediate signal that RAM is insufficient. The bi (blocks in from storage) and bo (blocks out to storage) columns show overall storage I/O volume, but without distinguishing cache misses from genuine write activity.

For a direct cache hit rate measurement, the cachestat tool from the BCC eBPF toolkit provides per-second cache hit and miss counts. On KVM VPS plans with a modern kernel where eBPF is available, this gives precise visibility into whether your RAM-to-dataset ratio is appropriate. On OpenVZ, eBPF tooling is typically unavailable, but vmstat and /proc/meminfo still provide sufficient signal.

Practical RAM Optimisation for Common Stacks

Beyond sizing, several application-level and kernel-level configurations directly affect how efficiently a VPS uses its available RAM.

MySQL and MariaDB

The single most impactful configuration for MySQL memory usage is innodb_buffer_pool_size — the memory InnoDB uses to cache table data and indexes. This should be set to 70–80% of total available RAM on a dedicated database VPS, or 40–60% on a mixed-workload server. Set it in /etc/mysql/conf.d/. Too small and disk I/O dominates; too large and the OS has insufficient memory for its own page cache and process overhead, causing kernel-level memory pressure.

PostgreSQL

PostgreSQL’s primary memory parameter is shared_buffers — the dedicated database buffer cache, set to 25% of total RAM as a starting point. Unlike MySQL’s InnoDB buffer pool, PostgreSQL also relies heavily on the OS page cache (it calls this “effective_cache_size”), so the optimal shared_buffers is lower than MySQL’s equivalent. The work_mem parameter controls per-sort and per-hash operation memory — this multiplies by the number of concurrent queries and sort operations, so set it conservatively (4–16 MB) unless you have ample RAM headroom.

Redis

Redis stores its entire dataset in memory by default with no upper limit — making it capable of consuming all available RAM and triggering an OOM kill. Always configure maxmemory in redis.conf to a value below your available RAM, and set maxmemory-policy to an appropriate eviction strategy (allkeys-lru for caching use cases). Redis’s INFO memory command reports used_memory_rss — the actual physical RAM consumed including fragmentation — which is the figure to monitor for capacity planning.

PHP-FPM

PHP-FPM’s memory consumption is driven by pool size: the number of worker processes multiplied by average per-process memory. A typical PHP process handling a WordPress request uses 30–60 MB. A pool of 20 workers therefore requires 600 MB–1.2 GB just for PHP, before accounting for the MySQL or MariaDB instance, nginx, and OS overhead. Right-size your pm.max_children in /etc/php-fpm.d/ based on available RAM divided by average process size, not based on connection capacity targets — an oversized pool that triggers OOM kills serves fewer requests, not more.