Dedicated server RAM requirements at a glance
RAM is the working space used by the Linux kernel, application processes, filesystem cache, databases, containers, and background jobs. A server can use nearly all available memory without being unhealthy because Linux deliberately uses unused RAM for page cache. The warning signs are sustained swap activity, out-of-memory kills, high disk wait time, and latency that rises as concurrent users increase.
A good sizing target is to keep normal peak usage below 70–80% of physical RAM. That leaves capacity for traffic bursts, scheduled jobs, filesystem cache, database buffers, and a failed process restarting. Servers that consistently operate above 90% memory usage may work until a backup, deployment, database query, or player spike causes swapping or the kernel OOM killer terminates a process.
Takeaway: choose RAM from the workload scale below, then add 25–50% headroom if traffic is growing, backups run locally, or several services share the same dedicated server.
| Workload scale | Recommended specification | Typical memory allocation | Examples |
|---|---|---|---|
| Single lightweight service | 4–8 CPU cores, 16 GB RAM, 240 GB NVMe | 2–8 GB active use | Small WordPress site group, VPN, monitoring node, one small game server |
| Small production stack | 6–8 CPU cores, 32 GB RAM, 480 GB NVMe | 12–24 GB active use | Web hosting, mail server, Docker host, 2–4 game instances, small PostgreSQL or MySQL database |
| Growing application or database | 8–12 CPU cores, 64 GB RAM, 1 TB NVMe | 28–50 GB active use | Busy WooCommerce store, SaaS application, CI runners, Redis cache, medium database |
| High-concurrency or multi-service | 12–16 CPU cores, 128 GB RAM, 2 TB NVMe | 60–100 GB active use | Virtualization host, large game community, mail platform, high-traffic database, video processing |
| Memory-intensive platform | 16–32 CPU cores, 256 GB RAM or more, 2 TB+ enterprise NVMe | 140–220 GB active use | Large PostgreSQL/MySQL datasets, Elasticsearch clusters, analytics, dense VMs, private cloud nodes |
How RAM is used on a dedicated server
Application memory is only part of the total. Linux uses RAM for page cache, which keeps recently accessed files, database pages, logs, and assets available without another disk read. This is beneficial: a database that has enough RAM to cache its working dataset can answer many reads far faster than one that constantly fetches pages from NVMe storage.
- Operating system and services: A minimal Linux installation may use 500 MB to 2 GB, but control panels, antivirus tools, monitoring agents, and backup clients add more.
- Web stack: Nginx is usually light, while Apache with prefork PHP can consume substantial memory per concurrent request. PHP-FPM limits make usage more predictable.
- Databases: MySQL, MariaDB, and PostgreSQL use configured buffer pools plus per-connection memory. Poor connection limits can exhaust memory quickly.
- Containers and virtual machines: Docker containers share the host kernel, but virtual machines each need assigned guest RAM plus some hypervisor overhead.
- Caches: Redis, Memcached, Elasticsearch, and application caches intentionally exchange RAM for lower latency.
- Filesystem cache: Linux reclaims cache automatically under pressure, but cache is valuable for web assets, package builds, and frequently read data.
Check the actual situation with free -h, vmstat 1, and ps aux --sort=-%mem | head -20. In the output from free -h, focus on the available value rather than treating all cache as unavailable memory.
RAM by workload
Web hosting and CMS sites: 16–64 GB
A dedicated server hosting a few low-traffic WordPress, Laravel, or static sites can operate well with 16 GB RAM if Nginx, PHP-FPM, and a small database are tuned. Move to 32 GB when the server hosts multiple dynamic sites, runs a hosting control panel, processes frequent cron jobs, or supports e-commerce traffic. A 64 GB server is a sensible baseline for many busy WooCommerce, Magento, or custom application stacks because it allows database caching and leaves room for PHP workers.
Estimate PHP-FPM capacity from real process size. If each worker uses 120 MB and the server safely reserves 6 GB for the OS, database, cache, and headroom on a 32 GB machine, allocating 12 GB to PHP permits roughly 100 workers. Do not set 100 workers automatically: CPU cores, upstream database capacity, and request duration also limit useful concurrency.
Databases: 32 GB to 256 GB or more
Database sizing is driven by the active working set, not simply total disk size. A 500 GB database may perform well on 64 GB RAM if only 30 GB of indexes and recently queried rows are active. Conversely, a 40 GB database can need 128 GB if analytical queries, many connections, and large joins run concurrently.
For MySQL or MariaDB, start with an InnoDB buffer pool sized around 50–70% of RAM on a database-only server. On a 64 GB dedicated database server, a 36–44 GB buffer pool is a practical initial range. Leave memory for the OS, connection buffers, temporary tables, backups, and monitoring. PostgreSQL needs similar discipline: shared buffers are only one component, while work_mem is multiplied by sorts, hashes, and concurrent queries.
Game servers: 16–128 GB
Game server memory use varies more by game engine, mods, map size, and player count than by network speed. A single vanilla Minecraft server may fit in 4–8 GB, but modpacks and large worlds commonly need 10–16 GB per instance. A dedicated server with 32 GB RAM can support a modest community and associated web panel, while 64 GB is more suitable for multiple modded instances or a larger player base.
Rust, ARK: Survival Evolved, and heavily modded survival servers can use 16–32 GB or more for one active instance. For a community operating several game worlds, 128 GB provides safer consolidation capacity. CPU single-thread performance remains critical for tick-rate-sensitive games, so more RAM should not replace adequate high-frequency CPU cores.
Mail servers: 16–64 GB
A small mail server running Postfix, Dovecot, Rspamd, antivirus scanning, and spam filtering can start at 16 GB. Use 32 GB for a production mail platform with many active mailboxes, attachment scanning, and local message queues. Select 64 GB if the server processes large inbound volumes, retains extensive spam-filter data, or runs database and webmail services locally. Mail systems also require fast storage and careful DNS, reverse DNS, SPF, DKIM, and DMARC configuration; RAM alone does not determine delivery quality.
Streaming and media services: 32–128 GB
Video streaming often becomes CPU-bound during transcoding, but RAM matters for concurrent ffmpeg jobs, thumbnails, metadata databases, and caching. A direct-play media server can start at 16–32 GB. A server performing multiple 1080p transcodes is better placed at 32–64 GB, while 4K transcoding, large media libraries, or several simultaneous encode jobs can justify 128 GB. Hardware encoding can reduce CPU pressure, but it does not remove the need for memory headroom.
CI/CD, builds, and development platforms: 32–128 GB
Compile jobs, container image builds, browser-based tests, and parallel CI runners consume memory in bursts. A 32 GB dedicated server works for one or two modest runners. Use 64 GB for parallel builds and self-hosted Git services, and 128 GB when several runners compile large Java, Android, Rust, C++, or frontend projects simultaneously. Configure runner concurrency according to both CPU and RAM; eight jobs on eight cores are unsafe if each build can consume 6 GB.
Virtualization and self-hosted application stacks: 64–256 GB
A virtualization host needs physical RAM for every guest, plus host overhead and cache. For example, six VMs assigned 6 GB each require at least 36 GB before allowing for the hypervisor, filesystem cache, and growth. A 64 GB dedicated server is a reasonable starting point for a few production VMs. Choose 128 GB or 256 GB for denser VM fleets, Kubernetes worker nodes, or self-hosted stacks containing Nextcloud, GitLab, monitoring, databases, and object storage.
Performance test methodology and tools
RAM decisions should be verified with a repeatable benchmark rather than guessed from a single dashboard graph. The following reference profile uses an 8-core dedicated server, 64 GB DDR5 RAM, a 1 TB NVMe drive, and a 1 Gbps network port. Tests run on an otherwise idle Linux host, use local storage, and are repeated three times; the median result is reported. Results vary by CPU generation, NVMe model, RAID layout, datacenter route, kernel version, and noisy application load.
- CPU:
sysbench cpu --cpu-max-prime=20000 --threads=8 runmeasures integer-prime calculation throughput. - Memory:
sysbench memory --memory-block-size=1M --memory-total-size=100G runtests memory copy throughput. - Disk I/O:
fio --name=randread --filename=/srv/fio.test --size=20G --bs=4k --rw=randread --iodepth=32 --numjobs=4 --direct=1 --runtime=60 --time_basedtests random-read IOPS without relying on page cache. - Network:
iperf3 -c benchmark.example.net -P 4 -t 30measures TCP throughput to a suitable remote endpoint. Test several geographic locations. - Application load:
wrk -t4 -c100 -d60s https://server.example/measures web response capacity at 100 concurrent connections.
Reference CPU, disk, network, and memory benchmark results
| Test | Reference result | What it indicates | RAM relevance |
|---|---|---|---|
| Sysbench CPU, 8 threads | 1,180 events per second | Compute capacity for application code, compression, and game ticks | More RAM does not increase this result unless swapping was occurring |
| Sysbench memory copy | 31.6 GiB/s | Memory bandwidth for cache-heavy and parallel workloads | Useful for databases, builds, and virtual machines |
| fio 4 KiB random read | 286,000 IOPS, 1.09 GiB/s | Small-block storage responsiveness | Insufficient RAM causes more reads to reach this layer |
| fio 1 MiB sequential write | 1.72 GiB/s | Backup, media, and large-file write throughput | Write buffers smooth short bursts but do not replace durable storage |
| iperf3, 4 streams, 1 Gbps port | 941 Mbps | Practical TCP throughput after protocol overhead | High connection counts require memory for socket buffers |
| wrk, 100 connections, cached PHP endpoint | 1,850 requests/second, p95 74 ms | Web stack response under controlled load | Page cache and database buffers reduce disk waits |
These numbers show why RAM affects application performance indirectly. The NVMe drive is fast, but a database page served from memory avoids a storage request altogether. If insufficient RAM forces swap I/O, latency may increase from milliseconds to hundreds of milliseconds under load.
Real-world application performance effects
Database-backed website: A 32 GB server that reserves 16 GB for MySQL buffers, 6 GB for PHP-FPM, and the remaining capacity for the OS and cache can handle moderate dynamic traffic predictably. If the same site receives a campaign-driven traffic spike and memory reaches 95%, new PHP workers and database temporary tables can push the host into swap. A 64 GB configuration often improves p95 latency more than additional CPU cores because it keeps hot database pages and web assets cached.
Minecraft community: A 16 GB server may run one 10 GB modded instance, but scheduled world saves and plugin activity leave little reserve. A 32 GB server gives the Java heap room while preserving memory for Linux cache and management tooling. Assigning every available GB to the Java heap is counterproductive because the host also needs memory.
PostgreSQL analytics workload: A reporting server with 100 GB of frequently accessed indexes and tables benefits materially from 128 GB RAM. It can retain more hot data in cache, reducing random NVMe reads during dashboards and report generation. Query plans and indexes remain necessary; adding RAM cannot repair an inefficient full-table scan.
CI build host: Four concurrent container builds using 7 GB each can exceed a 32 GB server once the host, Docker cache, and test processes are included. A 64 GB configuration supports the same jobs with a practical reserve, while 128 GB is appropriate if parallel browser tests and compilation run together.
Optimization recommendations
Measure memory pressure, not just used RAM
Run free -h, vmstat 1, and sar -r 1 60 during peak load. In vmstat, sustained nonzero si and so values indicate swap-in and swap-out activity. Review kernel OOM events with journalctl -k | grep -i oom.
Set limits for every service
Use PHP-FPM pm.max_children, Docker memory limits, systemd MemoryMax=, database connection pools, and CI runner concurrency limits. A controlled queue is safer than allowing one service to consume all physical memory and terminate unrelated processes.
Tune database memory conservatively
Set buffer pools based on measured workload and leave headroom for connection memory. Monitor MySQL with mysqladmin extended-status or PostgreSQL with pg_stat_database. Add indexes and fix expensive queries before assuming the only answer is more RAM.
Use fast NVMe storage and avoid sustained swap
NVMe reduces the penalty of cache misses, backups, and database reads, but it cannot make swap acceptable for a busy production service. Keep a small swap area as emergency protection, set a conservative swappiness value where appropriate, and investigate any persistent swapping.
Separate incompatible workloads
A database, transcoding worker, CI runner, and game server can compete for RAM and CPU at unpredictable times. Use separate dedicated servers for sustained, isolation-critical workloads. A VPS is often sufficient for a low-traffic VPN, monitoring node, small static site, or single lightweight service, but dedicated hardware is the better fit for active databases, game communities, large build systems, and multi-service production platforms.
Plan for growth and maintenance
Allow memory for database restores, backups, package upgrades, log processing, security scans, and traffic spikes. If peak usage already exceeds 80% of RAM, move to the next tier before an urgent incident forces the upgrade.