Hoeveel RAM heb je in 2025 echt nodig voor servers en VPS?

Het bepalen van de juiste hoeveelheid RAM is een berekening op basis van de werklast, geen benchmark. Geef je te veel uit, dan betaal je voor onbenutte capaciteit. Geef je te weinig uit, dan worden je processen afgebroken, wordt je database vanaf de schijf in plaats van vanuit het geheugen bediend, of worden je containers afgeremd. Deze gids geeft concrete RAM-bereiken voor de workloads die we het vaakst tegenkomen (webhosting, databases, virtualisatie, containers, AI-inferentie en gameservers), plus de regels die je moet volgen bij het bepalen van de benodigde hoeveelheid RAM voor iets dat niet op de lijst staat.

Wat RAM doet in een server

RAM bevat alles waar de server actief mee bezig is. Procesgeheugen voor webservers, database-engines en achtergronddaemons. Paginacache op besturingssysteemniveau en schijf-I/O-buffers. Runtime-geheugen voor applicaties en containers. En de geheugenblokken die worden toegewezen aan virtuele machines of container-workloads.

Wat het bepalen van de RAM-grootte anders maakt dan het bepalen van de CPU-grootte, is de storingsmodus. Raakt de CPU vol, dan vertragen processen. Raakt het RAM vol, dan swapt de kernel (traag) of kiest de OOM-killer een slachtoffer en beëindigt het. Het eerste voelt vervelend aan. Bij de tweede gaan gegevens verloren. Het inplannen van RAM met een marge is geen luxe, maar zorgt ervoor dat het systeem onder belasting niet instort.

RAM per werklast

Web- en applicatieservers

• Lichte LAMP- of LEMP-stack: 1 tot 2 GB
• WordPress of CMS met caching (bijv. Redis): 2 tot 4 GB
• E-commerce (Magento, WooCommerce): 4 tot 8 GB
• Node.js-, Django- of Rails-apps: 2 tot 6 GB

Cachinglagen zoals Redis of Varnish hebben naast de basisbehoefte van de applicatie ook eigen RAM nodig. PHP-FPM-workers, databaseverbindingen en reverse proxies verbruiken allemaal gelijktijdig geheugen, dus het cijfer dat ertoe doet is de piekparallelliteit, niet het geheugengebruik in ruststand.

Databaseservers (SQL en NoSQL)

• MySQL of PostgreSQL (klein): 4 tot 8 GB
• MySQL of PostgreSQL (groot of met veel verkeer): 16 tot 64 GB
• MongoDB of Redis (gericht op in-memory): 32 tot 128 GB of meer
• Elasticsearch- of OpenSearch-knooppunten: 32 tot 128 GB per knooppunt

Het doel is om de werkverzameling, de indexen en de rijen die vaak worden geraadpleegd in het RAM-geheugen te houden. Zodra een van deze gegevens naar de schijf wordt verplaatst, neemt de latentie met ordes van grootte toe, hoe snel de SSD ook is.

Virtualisatiehosts (Proxmox, VMware, Hyper-V)

• Lichtgewicht Linux-VM's: 2 tot 4 GB per VM
• Windows-VM's: 8 tot 12 GB per VM
• Hostingpanelen (cPanel, Plesk, DirectAdmin): 4 tot 8 GB per instantie
• KVM- of LXC-containerhosts: 32 tot 128 GB of meer

Reserveer altijd 4 tot 8 GB voor het host-besturingssysteem zelf, bovenop de toewijzingen voor gasten. Containers gebruiken minder RAM per workload dan volledige VM's, maar schalen anders, dus houd rekening met dichtheid en ruimte voor pieken in plaats van met de grootte per container. Als de host ZFS gebruikt, houd dan ook rekening met de ARC, die standaard stilzwijgend tot de helft van het systeem-RAM in beslag neemt en concurreert met de toewijzingen aan gasten (onze ZFS ARC-tuninggids behandelt de juiste limieten voor hypervisor-workloads).

Containers en microservices (Docker, Kubernetes)

• Eenvoudige Docker-stacks (web, app, DB): 8 tot 16 GB
• Docker Swarm- of K3s-edge-knooppunten: 16 tot 32 GB
• Kubernetes-werkknooppunten: 32 tot 128 GB
• CI/CD-runners en build-agents (GitLab, Jenkins): 8 tot 32 GB per runner

Let op geheugenlekken bij langlopende containers. JVM-gebaseerde workloads zoals Kafka en Elasticsearch hebben hogere basiswaarden nodig, omdat de heap zich uitbreidt tot waar je hem de ruimte geeft, wat vaak meer is dan je had verwacht.

AI- en ML-inferentie

• Kleine modellen (gekwantiseerde BERT, Llama 7B): 16 tot 32 GB
• Middelgrote modellen (13B tot 30B, gekwantiseerd): 64 tot 128 GB
• Grote modellen (40B+ of niet-gekwantiseerde middenklasse): 128 tot 512 GB of meer
• Door GPU ondersteunde inferentie (Stable Diffusion, Whisper): 32 tot 128 GB, afhankelijk van de offload

Door kwantisering verschuift de druk op het geheugen van de GPU naar het RAM-geheugen van de CPU, waardoor de systeemspecificaties aanzienlijk veranderen, afhankelijk van of je fp16 op de GPU of 4-bit op de CPU verwerkt. Ook de batchgrootte en de lengte van de prompts zorgen ervoor dat de benodigde hoeveelheden toenemen. In onze gids over AI-inferentiehosting gaan we dieper in op het afstemmen van hardware op de grootte van het model.

Gameservers

• Minecraft (vanilla): 2 tot 4 GB
• Minecraft (gemodificeerd): 6 tot 16 GB
• Rust, ARK of 7 Days to Die: 8 tot 16 GB
• Hostingknooppunten met meerdere instanties: 32 tot 64 GB

Gespecialiseerde workloads

• Videotranscodering (FFmpeg, Plex): 16 tot 64 GB
• Back-up- of snapshot-servers: 8 tot 16 GB, meer indien er deduplicatie-engines draaien
• Firewall of IDS (pfSense, Suricata): 2 tot 8 GB, meer voor NetFlow of volledige pakketlogging

Vertrouw niet op swapgeheugen

Swap is 10 tot 100 keer langzamer dan RAM. Het dient als vangnet, zodat de kernel ergens terecht kan wanneer de geheugendruk piekt, niet als een manier om het bruikbare geheugen uit te breiden. Als een server bij normale belasting al op swap terechtkomt, is hij simpelweg ondergedimensioneerd, punt uit. In het artikel ‘Hoe Linux-swap, de OOM-killer en cgroups op elkaar inwerken’ worden de storingsmodi uitgebreid behandeld.

Hoe u de benodigde hoeveelheid RAM nauwkeurig kunt bepalen

1. Meet de piek, niet het gemiddelde. Gebruik htop, free -m, vmstat 1of je Kubernetes-metrics om het piekgebruik over een volledige verkeerscyclus te bepalen. Dagelijkse pieken, wekelijkse batches en maandelijkse factureringsrondes zijn allemaal van belang.
2. Houd rekening met ruimte voor groei. 20% tot 50% voor het opschalen van applicaties. Voor databases: schaal het geheugen op basis van de grootte van de dataset, niet op basis van het aantal verzoeken. Voor multi-tenant-platforms: bereken de benodigde capaciteit per klant en vermenigvuldig dit.
3. Plan op basis van de storingsmodus die u kunt tolereren. Een leesreplica met te weinig RAM presteert slechter. Een primaire database met te weinig RAM beschadigt query’s en kan applicaties mee ten val brengen. Besteed het RAM-geheugen daar waar de impact het grootst is.

RAM is de specificatie waarbij een tekort meer schade veroorzaakt dan een overschot. Het toevoegen van geheugen maakt een CPU-gebonden applicatie niet sneller, maar te krap werken ondermijnt de stabiliteit. Bepaal de omvang op basis van daadwerkelijke monitoring en uw geteste pieken, en houd vervolgens ruimte over.

FDC biedt dedicated servers en VPS-oplossingen met configuraties met veel RAM en onbeperkte bandbreedte in meerdere regio’s.