Hoeveel RAM voor een VPS: de regel, toepassing per toepassing

De regel: optellen wat in het geheugen blijft

Een server verbruikt geen geheugen “in het algemeen”: elk programma dat draait, houdt er een deel van vast, zolang het draait. De berekening begint dus bij de lijst van processen die permanent aanwezig zijn, en telt daar de piek en een marge bij op:

Benodigd geheugen = (systeem + permanente diensten + piek van incidentele taken) × 1,25

• Het systeem: een minimale Linux-distributie (Debian, Ubuntu) neemt na het opstarten zo’n 150 tot 300 MB in beslag, SSH-toegang en logging inbegrepen.
• De permanente diensten: webserver, processen van de applicatie, database, cache, takenwachtrij. Hun verbruik hangt af van de technologie, uitgewerkt in de volgende sectie.
• De piek: wat er af en toe bijkomt, zoals het bouwen van de applicatie, een back-up, een import of een zware geplande taak. Een server die op zijn gemiddelde is gedimensioneerd, valt precies op die momenten om.
• De marge: 25% boven het totaal, voor de groei van gegevens en verkeer. Ze ligt niet stil: Linux gebruikt vrij geheugen als bestandscache, wat de database sneller maakt.

Wat elk onderdeel verbruikt

De ordes van grootte hieronder gelden voor een applicatie van gangbare omvang, gemeten in productie. Ze geven een vertrekpunt; de meting op uw eigen applicatie, verderop beschreven, heeft altijd het laatste woord.

Eén piek duikt bij JavaScript-applicaties telkens weer op: de build. npm run build op een Next.js-, Nuxt- of Angular-project vraagt alleen al gewoonlijk 1 tot 2 GB, een paar minuten lang, bovenop wat er al draait. Op de server bouwen betekent dimensioneren voor die piek; bouwen op uw eigen computer of in uw CI-pipeline en alleen het resultaat uitrollen, vermijdt hem.

Dezelfde redenering geldt voor Docker-containers: elke container is een verzameling processen zoals alle andere, en de Docker-daemon voegt zijn eigen verbruik toe. docker stats toont wat elke container inneemt.

Typische profielen

Deze profielen tellen de onderdelen hierboven op, piek en marge inbegrepen. Ze gaan uit van een applicatie van gangbare omvang en het verkeer van een lancering; een omvangrijke database of aanhoudend verkeer schuift de wijzer naar boven.

Een applicatie die een AI-model via een API aanroept (OpenAI, Anthropic, Mistral), dimensioneert u zoals elke webapplicatie: het model draait bij de aanbieder, en uw server wacht op het antwoord. Het is het draaien van het model op de server zelf dat de schaal verandert.

Meten op een draaiende server

Op een server in productie vervangt de meting de schatting. Drie commando’s vertellen waar u staat:

free -h
ps aux --sort=-rss | head -n 15
vmstat 5 5

• free -h: lees de kolom available, het geheugen dat werkelijk beschikbaar is om nieuwe programma’s te starten. De kolom free is bijna altijd laag, en dat is normaal: Linux vult ongebruikt geheugen met bestandscache (buff/cache), die het teruggeeft zodra een programma er behoefte aan heeft.
• ps aux --sort=-rss: de processen gerangschikt naar ingenomen geheugen (kolom RSS, in kilobytes). Hier ziet u wat elke PHP- of Node.js-worker weegt.
• vmstat 5 5: vijf metingen met telkens vijf seconden ertussen. Waarden die niet nul zijn in de kolommen si en so, meting na meting, wijzen op een server die naar swap uitwijkt: hij komt geheugen tekort.

Meet op het drukste moment van de dag, en tijdens de incidentele taken: build, back-up, import. De piek is wat telt.

Als het geheugen opraakt

Een server zonder geheugen wordt niet geleidelijk trager. Als er niets meer vrij te maken is, zet de Linux-kernel de OOM killer (out of memory) in: die kiest een proces, meestal het proces dat het meeste geheugen inneemt, en stopt het abrupt. Op een applicatieserver is dat vaak de database.

De symptomen: af en toe 502- of 503-fouten, een dienst die zonder zichtbare reden herstart, een build die afbreekt met Killed. De logs bevestigen het:

journalctl -k | grep -i "out of memory"
systemctl status naam-van-de-dienst

In de uitvoer van systemctl status wijst de vermelding Failed with result 'oom-kill' op een dienst die is gestopt door geheugentekort.

Swap, als de server die heeft, stelt dat moment uit door het minst gebruikte geheugen naar schijf te verplaatsen. Het is een vangnet, geen capaciteit: een server die voortdurend op swap leunt, reageert meerdere keren trager, zelfs op een NVMe-SSD.

De oplossingen, van eenvoudigst tot duurzaamst: het aantal processen van de applicatie verlagen (pm.max_children, Gunicorn-workers), buiten de server bouwen, het geheugen van de database begrenzen, en daarna overstappen naar een groter formaat.

Uw formaat kiezen, en vooruitkijken

1. Maak een lijst van wat er zal draaien: webserver, applicatie en aantal processen, database, cache, geplande taken.
2. Tel alles op met de tabel van de onderdelen, voeg de zwaarste piek toe (vaak de build), en daarna 25% marge.
3. Kies het formaat dat dat totaal dekt. Tussen twee naburige formaten volstaat het kleinste, zolang de overstap naar een groter formaat zonder herinstallatie verloopt.
4. Meet na de livegang, op de piek van de dag, en daarna bij elke groeistap van de applicatie.

Geheugen is niet de enige resource: de processor telt voor alles wat rekent (builds, beeldbewerking, het draaien van een AI-model), de schijf voor de database en de bestanden. Voor een webapplicatie is het toch bijna altijd het geheugen dat het formaat bepaalt.