Hur mycket RAM behöver en VPS? Regeln och vad varje del kräver

Regeln: summera det som ligger kvar i minnet

En server förbrukar inte minne ”i allmänhet”: varje program som körs håller en del av det så länge det körs. Beräkningen utgår därför från listan över processer som alltid finns där, och lägger sedan till toppen och en marginal:

Minne att planera för = (system + ständiga tjänster + topp från tillfälliga jobb) × 1,25

• Systemet: en minimal Linux-distribution (Debian, Ubuntu) tar ungefär 150 till 300 MB när den har startat, SSH-åtkomst och loggning inräknade.
• De ständiga tjänsterna: webbserver, applikationens processer, databas, cache, jobbkö. Hur mycket de förbrukar beror på tekniken, som beskrivs i nästa avsnitt.
• Toppen: det som tillkommer ibland, som kompilering av applikationen, säkerhetskopiering, import eller ett tungt schemalagt jobb. En server som dimensioneras efter sitt genomsnitt faller just i de ögonblicken.
• Marginalen: 25 % över summan, för växande data och trafik. Den ligger inte oanvänd: Linux använder ledigt minne som filcache, vilket snabbar upp databasen.

Vad varje del förbrukar

Storleksordningarna nedan gäller för en applikation av vanlig storlek, uppmätta i produktion. De är en utgångspunkt; mätningen på din egen applikation, som beskrivs längre ned, har alltid sista ordet.

En topp återkommer ofta i JavaScript-applikationer: kompileringen. npm run build i ett Next.js-, Nuxt- eller Angular-projekt kräver ofta 1 till 2 GB på egen hand under några minuter, utöver det som redan körs. Att kompilera på servern innebär att dimensionera för den toppen; att kompilera på din egen dator eller i din CI-miljö och bara lägga upp resultatet undviker den.

Samma resonemang gäller Docker-containrar: varje container är en uppsättning processer som alla andra, och Docker-daemonen lägger till sin egen förbrukning. docker stats visar vad var och en tar.

Typiska profiler

Profilerna summerar delarna ovan, topp och marginal inräknade. De förutsätter en applikation av vanlig storlek och trafiken vid en lansering; en stor databas eller en jämnt hög trafik flyttar siffran uppåt.

En applikation som anropar en AI-modell via API (OpenAI, Anthropic, Mistral) dimensioneras som vilken webbapplikation som helst: modellen körs hos leverantören, och din server väntar på svaret. Det är när modellen körs på själva servern som skalan ändras.

Mät på en server i drift

På en server i drift ersätter mätningen uppskattningen. Tre kommandon visar var du står:

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

• free -h: läs kolumnen available, det minne som verkligen finns tillgängligt för att starta nya program. Kolumnen free är nästan alltid låg, och det är normalt: Linux fyller oanvänt minne med filcache (buff/cache), som lämnas tillbaka så snart ett program behöver det.
• ps aux --sort=-rss: processerna sorterade efter använt minne (kolumnen RSS, i kilobyte). Här ser du vad varje PHP- eller Node.js-worker väger.
• vmstat 5 5: fem mätningar med fem sekunders mellanrum. Värden över noll i kolumnerna si och so, mätning efter mätning, betyder att servern swappar: den har för lite minne.

Mät vid dygnets mest belastade tidpunkt, och under de tillfälliga jobben: kompilering, säkerhetskopiering, import. Det är toppen som räknas.

När minnet tar slut

En server som får slut på minne blir inte gradvis långsammare. När det inte finns något kvar att frigöra startar Linuxkärnan OOM killer (out of memory): den väljer en process, oftast den som tar mest minne, och stoppar den direkt. På en applikationsserver är det ofta databasen.

Symtomen: 502- eller 503-fel då och då, en tjänst som startar om utan synbar anledning, en kompilering som avbryts med Killed. Loggarna bekräftar det:

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

I utdata från systemctl status anger Failed with result 'oom-kill' en tjänst som har stoppats på grund av minnesbrist.

Swap, om servern har det, skjuter upp det ögonblicket genom att flytta det minst använda minnet till disk. Det är ett skyddsnät, inte kapacitet: en server som hela tiden lutar sig mot swap svarar flera gånger långsammare, även på en NVMe-SSD.

Åtgärderna, från den enklaste till den mest hållbara: minska antalet processer i applikationen (pm.max_children, Gunicorn-workers), kompilera utanför servern, begränsa databasens minne och gå sedan upp till en större storlek.

Välj storlek, och planera för framtiden

1. Lista det som ska köras: webbserver, applikation och antal processer, databas, cache, schemalagda jobb.
2. Summera med tabellen över komponenterna, lägg till den tyngsta toppen (ofta kompileringen) och sedan 25 % marginal.
3. Välj den storlek som täcker summan. Mellan två närliggande storlekar räcker den mindre, så länge bytet till en större storlek sker utan ominstallation.
4. Mät efter lanseringen, vid dygnets topp, och sedan vid varje tillväxtsteg för applikationen.

Minnet är inte den enda resursen: processorn spelar roll för det som räknar (kompilering, bildbehandling, körning av en AI-modell), disken för databasen och filerna. För en webbapplikation är det ändå nästan alltid minnet som bestämmer storleken.