Hoeveel server heb je nodig? CPU, RAM en opslag dimensioneren per workload

Eerst het antwoord: de methode

Dimensioneren is drie getallen die je met elkaar vermenigvuldigt, geen gok:

1. Basislijn: wat de workload verbruikt onder normale belasting. Meet dit als de workload al ergens bestaat (een VPS, een staging-server, je laptop onder loadtesting); schat het met de vuistregels hieronder als dat niet zo is.
2. Marge: vermenigvuldig met 1.5–2×. Marge vangt trafficpieken, achtergrondtaken en de prestatieklif op die elk systeem tegenkomt bij bijna-verzadiging (een database op 90% RAM presteert veel slechter dan een op 60%, niet 30% slechter).
3. Groei: reken over de hele looptijd, niet over de eerste week na livegang. Groeien de gegevens met 10 GB/maand, dan heb je over een jaar 120 GB meer nodig dan vandaag.

En één vuistregel die de duurste categorie fouten voorkomt: dimensioneer RAM en opslag ruim, CPU gematigd. Een te krap bemeten CPU maakt dingen trager; te weinig RAM of volle schijven maken dingen stuk. CPU is ook de resource die workloads het vaakst overschatten (de meeste servers staan de meeste tijd stationair), terwijl RAM juist de resource is die ze het vaakst onderschatten.

Wil je gewoon standaardwaarden, hier zijn eerlijke uitgangspunten; de rest van het artikel is de redenering om ze bij te stellen:

CPU: cores versus clocksnelheid

De wapenwedloop rond core-aantallen overschaduwt de vraag die ertoe doet: is je workload parallel of serieel?

• Parallelle workloads (virtualisatie, CI, video-encoding, request-zware API's) schalen met het aantal cores. Koop cores.
• Seriële workloads (gameserver-ticks, single-threaded applicatielussen, veel databasequerypaden) worden begrensd door de snelheid van één core. Koop clocksnelheid (en een nieuwere microarchitectuur), geen cores; vierenzestig trage cores verliezen het van acht snelle, en dit is de meest voorkomende dimensioneringsfout bij gameservers.
• Gemengde realiteit: een webstack is parallel over requests heen, maar elke request zelf is serieel, dus een middenklasse aantal cores met sterke per-core-prestaties past het best, en dat is waarom de meeste webworkloads daar hun sweet spot vinden.

Praktische kanttekeningen: hyperthreads zijn geen cores (reken ze als ~+20–30% throughput, niet ×2); virtualisatiehosts kunnen CPU behoorlijk oversubscriben (guests pieken zelden tegelijk, vandaar de ×0.7 in de tabel), maar mogen nooit RAM oversubscriben.

RAM: de resource waar je spijt van krijgt als je erop bezuinigt

Vuistregels die standhouden:

• Databases: de working set (de data die daadwerkelijk regelmatig wordt aangeraakt) moet met ruimte over in RAM passen. De grootste hendel voor databaseprestaties is niet query tuning, maar of reads uit het geheugen komen of van schijf. Schat de hot set (vaak 10–30% van de totale data), tel de indexen erbij op, en vermenigvuldig met 1.5.
• Virtualisatie: RAM is in bijna elke praktijksituatie de bindende beperking voor VM-dichtheid. Hosts hebben eerder geen geheugen meer dan geen CPU. Tel de allocaties van je guests op, reken daar 4–8 GB bovenop voor de host (meer bij ZFS: de cache verbruikt gretig en nuttig alles wat er vrij is).
• Web/app: applicatieprocessen × footprint per proces, plus opcode-/objectcaches, plus OS file cache (dat is waarom "ongebruikt" RAM je schijfreads versnelt: Linux gebruikt elke inactieve gigabyte als cache).
• Het faalscenario dat je wilt vermijden is swappen onder belasting: als het RAM opraakt, degraderen de prestaties niet geleidelijk, maar storten ze in terwijl de schijf ligt te thrashen. Laat monitoring enige aanhoudende swapactiviteit zien onder normale belasting, dan is de server vandaag al te krap bemeten, niet binnenkort.

Opslag: capaciteit is de makkelijke helft

• Capaciteit: huidige data × groei over de looptijd + 30% speling (volle schijven corrumperen databases en blokkeren deploys op de slechtst denkbare momenten). Pas daarna de RAID-overhead toe. Bruikbare capaciteit is niet hetzelfde als ruwe capaciteit, en dat verschil is het onderwerp van onze gids over RAID-niveaus: mirrors halveren de capaciteit, pariteit kost één schijf.
• Prestaties: voor alles wat latency-gevoelig is (databases, VM-stores, drukke webapps) is het antwoord in 2026 NVMe, punt uit: het gat in random I/O ten opzichte van SATA-SSD's is groot en ten opzichte van HDD's is het categorisch. Draaiende schijven houden precies één rol over: goedkope bulkcapaciteit voor media, archieven en backuptargets, idealiter achter een NVMe-laag voor het hot path.
• Endurance: write-zware workloads (databases met veel churn, CI-scratch, video-ingest) verbruiken de write endurance van SSD's. Bij typische intensiteit is dit zelden een probleem, maar verwacht je dagelijks meerdere terabytes te herschrijven, meld dat dan bij het specificeren: er bestaan datacenter-grade drives met hogere endurance-ratings speciaal hiervoor.

Bandbreedte: rekenwerk, geen onderbuikgevoel

Reken maandelijks volume om naar constante snelheid met één factor: 1 TB/maand ≈ 3 Mbit/s constant gemiddelde. Een 1 Gbit/s-poort die volledig verzadigd is, verzet dus ~330 TB/maand, en dat vertelt je meteen dat de meeste workloads qua volume totaal niet poortgelimiteerd zijn. Wat de netwerkspecificatie werkelijk bepaalt:

• Pieken, geen gemiddelden. Traffic komt in bursts; een site die gemiddeld 30 Mbit/s draait kan tijdens een launch pieken tot honderden Mbit/s. Poortsnelheid koopt burstabsorptie.
• East-west traffic (replicatie, backups, opslagsync tussen je eigen servers) is waar 10 Gbit/s zichzelf terugverdient, lang voordat publiek verkeer dat doet. (Rekensom voor het backupvenster: het herstellen van 4 TB over 1 Gbit/s duurt ~9 uur; over 10 Gbit/s minder dan één. Dimensioneer de poort op de restore waar je op een dag zelf klam van wordt.)
• Latency is een eigenschap van locatie en netwerk, niet van poortsnelheid; gameservers en realtime-apps moeten eerst kiezen op nabijheid van het datacenter en netwerkkwaliteit (hier telt het draaien op het eigen, goed gepeerde ASN van een provider zwaarder dan het poortnummer).

Opschalen of uitschalen?

Groei je uit een server, dan zijn er twee richtingen, en welke de juiste is hangt af van de vorm van de workload:

Opschalen (een grotere server) zolang het kan: het is operationeel gratis (geen codewijzigingen, geen belasting van distributed systems) en dedicated hardware gaat ver omhoog voordat je het plafond raakt. Vooral databases hebben een voorkeur voor dit pad; gedistribueerde databases zijn een laatste redmiddel, geen groeiplan.

Uitschalen (meer servers) wanneer de workload zich natuurlijk laat opsplitsen: stateless web-/app-tiers achter een load balancer (ook je redundantieverhaal: twee middelgrote servers verslaan één grote op de dag dat een ervan een reboot nodig heeft), gameserver-instances per regio, CI-runners per wachtrij. De klassieke eerste opsplitsing is de database naar zijn eigen machine verhuizen: één migratie, en beide tiers krijgen een dedicated resourceprofiel dat past bij wat ze werkelijk nodig hebben (de cores van de webtier, het RAM en de NVMe van de database).

Veelgestelde vragen

Hoeveel RAM heeft mijn database echt nodig?

Ga uit van de hot set, niet van het totaal: een database van 500 GB waarvan de queries dagelijks 50 GB aan rijen en indexen aanraken, presteert prachtig met 96 GB RAM en beroerd met 16 GB, terwijl een zelden bevraagd archief van 2 TB probleemloos toekan met veel minder dan de omvang doet vermoeden. Bepaal de hot set waar mogelijk empirisch (cache-hitratio's in pg_stat/InnoDB-metrics op je bestaande systeem), tel de indexen en 50% speling erbij op, en controleer dit jaarlijks opnieuw. Hot sets groeien.

Heb ik een 10 Gbit/s-poort nodig?

Voor publiek verkeer waarschijnlijk niet: 1 Gbit/s verzet volledig verzadigd ~330 TB/maand, ruim boven wat de meeste sites nodig hebben. De workloads die oprecht 10 GbE willen, zitten tussen servers onderling: databasereplicatie, VM-migratie, gedistribueerde opslag en vooral backup-/restorevensters (een restore van meerdere terabytes op 1 Gbit/s is een dagvullend incident; op 10 Gbit/s is het een koffiepauze). Bevat je architectuur permanent datatransport tussen machines, specificeer het dan; besteed het verschil anders aan RAM.

Moet ik nu overprovisionen of later upgraden?

Overprovision de dingen die verstorend zijn om te wijzigen (RAM en opslag, waar een upgrade downtime en een onderhoudsvenster betekent) en koop CPU dichter bij de gemeten behoefte, want dat is het component dat in de praktijk het minst vaak wordt uitgeput. De 1.5–2×-margeregel bouwt al een jaar comfortabele groei in voor een typische workload; kijk daarboven eerlijk naar hoe pijnlijk een migratie voor dit systeem zou zijn. Stateless tier? Goedkoop om te verplaatsen, koop krap. Stateful database? Duur om te verplaatsen, koop ruim.

Wanneer heb ik echt een dedicated server nodig in plaats van een VPS?

Zodra een van deze zaken opgaat: aanhoudende CPU- of I/O-belasting die gedeelde platforms afknijpen of bestraffend afrekenen; een RAM-behoefte (64 GB+) waarbij dedicated pricing beter uitpakt dan gelijkwaardige VPS-tiers; latencygevoeligheid die geen luidruchtige buren verdraagt; of de behoefte aan volledige hardwarecontrole: hypervisors, custom kernels, kale NVMe. Piekerige, grotendeels inactieve workloads blijven het thuisterrein van de VPS; gestage, prestatiegevoelige workloads steken er verrassend vroeg overheen. Onze sectie over bare metal in de distro-gids gaat dieper in op deze grens.

Uitrollen op Serverside

De methode vertaalt zich direct naar onze dedicated server-configurator: kies per-core-snelle of many-core CPU's die passen bij de vorm van je workload, dimensioneer RAM en NVMe met de margeregel, en zie de rekensom van bruikbare RAID-capaciteit live toegepast terwijl je schijven kiest. Elke configuratie komt op ons eigen ASN 55285-netwerk terecht (goed gepeerd, met permanente DDoS-mitigatie) en staat binnen een minuut live, wat de strategie "begin redelijk, resize door opnieuw uit te rollen" ook echt praktisch maakt.

Eenmaal besteld: de hardeningchecklist voor het eerste uur, en als het plan is om de server in VM's op te delen, nemen onze Proxmox-gidsen het daarna over.