Hvor meget RAM skal en VPS have? Reglen, opgave for opgave

Reglen: læg det sammen, der bliver i hukommelsen

En server bruger ikke hukommelse «generelt»: hvert program, der kører, beholder en del af den, så længe det kører. Beregningen tager derfor udgangspunkt i listen over de processer, der kører permanent, og lægger derefter spidsbelastningen og en margin til:

Hukommelsesbehov = (system + permanente tjenester + spidsbelastning fra enkeltstående opgaver) × 1,25

• Systemet: en minimal Linux-distribution (Debian, Ubuntu) fylder i omegnen af 150 til 300 MB efter opstart, SSH-adgang og logning medregnet.
• De permanente tjenester: webserver, applikationens processer, database, cache, opgavekø. Deres forbrug afhænger af teknologien, som gennemgås i næste afsnit.
• Spidsbelastningen: det, der kommer oveni en gang imellem, som kompilering af en applikation, backup, import eller en tung planlagt opgave. En server, der er dimensioneret efter sit gennemsnit, går ned netop i de øjeblikke.
• Marginen: 25 % over totalen, til væksten i data og trafik. Den ligger ikke ubrugt hen: Linux bruger den frie hukommelse som filcache, hvilket gør databasen hurtigere.

Hvad hver komponent bruger

Størrelsesordenerne herunder gælder for en applikation af almindelig størrelse, målt i produktion. De giver et udgangspunkt; målingen på din egen applikation, som beskrives længere nede, har altid det sidste ord.

En spidsbelastning går ofte igen med JavaScript-applikationer: kompileringen. npm run build på et Next.js-, Nuxt- eller Angular-projekt kræver ofte 1 til 2 GB alene, i nogle minutter, oven i det, der allerede kører. At kompilere på serveren betyder at dimensionere efter den spidsbelastning; at kompilere på din egen computer eller i din CI-pipeline og kun lægge resultatet op undgår den.

Samme logik gælder for Docker-containere: hver container er en samling processer som alle andre, og Docker-dæmonen lægger sit eget forbrug til. docker stats viser, hvad hver enkelt bruger.

Typiske profiler

Disse profiler lægger komponenterne ovenfor sammen, spidsbelastning og margin medregnet. De forudsætter en applikation af almindelig størrelse og trafikken ved en lancering; en stor database eller vedvarende trafik flytter behovet opad.

En applikation, der kalder en AI-model via API (OpenAI, Anthropic, Mistral), dimensioneres som enhver anden webapplikation: modellen kører hos udbyderen, og din server venter på svaret. Det er, når modellen kører på selve serveren, at skalaen ændrer sig.

Mål på en server, der kører

På en server i drift erstatter målingen skønnet. Tre kommandoer viser, hvor du står:

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

• free -h: læs kolonnen available, den hukommelse, der reelt er til rådighed til at starte nye programmer. Kolonnen free er næsten altid lav, og det er normalt: Linux fylder den ubrugte hukommelse med filcache (buff/cache), som den giver tilbage, så snart et program har brug for den.
• ps aux --sort=-rss: processerne sorteret efter optaget hukommelse (kolonnen RSS, i kilobyte). Det er her, du ser, hvad hver PHP- eller Node.js-worker vejer.
• vmstat 5 5: fem målinger med fem sekunders mellemrum. Værdier over nul i kolonnerne si og so, måling efter måling, viser en server, der bytter med swap: den mangler hukommelse.

Mål på dagens travleste tidspunkt og under de enkeltstående opgaver: kompilering, backup, import. Det er spidsbelastningen, der tæller.

Når hukommelsen slipper op

En server, der mangler hukommelse, bliver ikke gradvist langsommere. Når der ikke er mere at frigøre, udløser Linux-kernen OOM killer (out of memory): den vælger en proces, som regel den, der optager mest hukommelse, og stopper den brat. På en applikationsserver er det ofte databasen.

Symptomerne: 502- eller 503-fejl en gang imellem, en tjeneste, der genstarter uden synlig grund, en kompilering, der afbrydes med Killed. Logfilerne bekræfter det:

journalctl -k | grep -i "out of memory"
systemctl status din-tjeneste

I outputtet fra systemctl status betyder Failed with result 'oom-kill', at en tjeneste er stoppet på grund af manglende hukommelse.

Swap, hvis serveren har det, udskyder det øjeblik ved at flytte den mindst brugte hukommelse ud på disken. Det er et sikkerhedsnet, ikke kapacitet: en server, der konstant læner sig op ad swap, svarer flere gange langsommere, selv på en NVMe-SSD.

Løsningerne, fra den enkleste til den mest holdbare: sænk antallet af applikationsprocesser (pm.max_children, Gunicorn-workers), kompilér uden for serveren, begræns databasens hukommelse, og skift derefter til en større størrelse.

Vælg din størrelse, og planlæg det næste skridt

1. List det, der skal køre: webserver, applikation og antal processer, database, cache, planlagte opgaver.
2. Læg sammen med tabellen over komponenter, tilføj den tungeste spidsbelastning (ofte kompileringen) og derefter 25 % margin.
3. Vælg den størrelse, der dækker totalen. Mellem to nabostørrelser er den mindste tilstrækkelig, så længe skiftet til den større størrelse sker uden geninstallation.
4. Mål efter lanceringen, på dagens travleste tidspunkt, og derefter ved hvert vækstskridt for applikationen.

Hukommelsen er ikke den eneste ressource: processoren tæller for det, der regner (kompilering, billedbehandling, kørsel af en AI-model), disken for databasen og filerne. For en webapplikation er det alligevel næsten altid hukommelsen, der bestemmer størrelsen.