Câtă memorie RAM pentru un VPS: regula, în funcție de utilizare

Regula: adunați ce rămâne în memorie

Un server nu consumă memorie „în general”: fiecare program care rulează își păstrează o parte din ea, cât timp rulează. Calculul pornește deci de la lista proceselor prezente permanent, apoi adaugă vârful și o marjă:

Memorie necesară = (sistem + servicii permanente + vârful sarcinilor ocazionale) × 1,25

• Sistemul: o distribuție Linux minimală (Debian, Ubuntu) ocupă în jur de 150 până la 300 MB după pornire, inclusiv accesul SSH și jurnalizarea.
• Serviciile permanente: serverul web, procesele aplicației, baza de date, cache-ul, coada de sarcini. Consumul lor depinde de tehnologie și este detaliat în secțiunea următoare.
• Vârful: ce se adaugă din când în când, precum compilarea unei aplicații, un backup, un import sau o sarcină programată grea. Un server dimensionat după media lui cedează exact în aceste momente.
• Marja: 25% peste total, pentru creșterea datelor și a traficului. Ea nu stă nefolosită: Linux folosește memoria liberă drept cache pentru fișiere, ceea ce accelerează baza de date.

Ce consumă fiecare componentă

Ordinele de mărime de mai jos sunt valabile pentru o aplicație de dimensiune obișnuită, măsurată în producție. Ele oferă un punct de plecare; măsurarea pe propria aplicație, descrisă mai jos, are întotdeauna ultimul cuvânt.

Un vârf revine des la aplicațiile JavaScript: compilarea. npm run build pe un proiect Next.js, Nuxt sau Angular cere frecvent între 1 și 2 GB doar pentru el, timp de câteva minute, pe lângă ce rulează deja. A compila pe server înseamnă a dimensiona pentru acest vârf; a compila pe calculatorul dumneavoastră sau în integrarea continuă și a depune doar rezultatul înseamnă a-l evita.

Același raționament este valabil pentru containerele Docker: fiecare container este un ansamblu de procese ca oricare altele, iar daemonul Docker își adaugă propriul consum. docker stats afișează cât ia fiecare.

Profiluri tipice

Aceste profiluri adună componentele de mai sus, cu vârf și marjă incluse. Ele presupun o aplicație de dimensiune obișnuită și traficul unei lansări; o bază de date voluminoasă sau un trafic susținut mută cursorul în sus.

O aplicație care apelează un model AI prin API (OpenAI, Anthropic, Mistral) se dimensionează ca orice aplicație web: modelul rulează la furnizorul său, iar serverul dumneavoastră îi așteaptă răspunsul. Rularea modelului pe serverul însuși este cea care schimbă ordinul de mărime.

Măsurarea pe un server care rulează

Pe un server în funcțiune, măsurarea înlocuiește estimarea. Trei comenzi arată unde vă aflați:

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

• free -h: citiți coloana available, memoria disponibilă efectiv pentru a lansa programe noi. Coloana free este aproape mereu mică, și este normal: Linux umple memoria nefolosită cu cache-ul fișierelor (buff/cache), pe care îl eliberează imediat ce un program are nevoie de el.
• ps aux --sort=-rss: procesele ordonate după memoria ocupată (coloana RSS, în kiloocteți). Aici vedeți cât cântărește fiecare worker PHP sau Node.js.
• vmstat 5 5: cinci citiri la interval de cinci secunde. Valorile nenule din coloanele si și so, citire după citire, semnalează un server care face schimb cu swap-ul: îi lipsește memoria.

Măsurați în momentul cel mai încărcat al zilei și în timpul sarcinilor ocazionale: compilare, backup, import. Vârful este cel care contează.

Când se termină memoria

Un server rămas fără memorie nu încetinește treptat. Când nu mai are nimic de eliberat, nucleul Linux declanșează OOM killer (out of memory): alege un proces, în general pe cel care ocupă cea mai multă memorie, și îl oprește brusc. Pe un server de aplicații, acesta este adesea baza de date.

Simptomele: erori 502 sau 503 din când în când, un serviciu care repornește fără motiv aparent, o compilare care se întrerupe cu mesajul Killed. Jurnalele confirmă:

journalctl -k | grep -i "out of memory"
systemctl status numele-serviciului

În rezultatul comenzii systemctl status, mențiunea Failed with result 'oom-kill' desemnează un serviciu oprit din lipsă de memorie.

Swap-ul, când serverul dispune de el, amână acest moment mutând pe disc memoria cel mai puțin folosită. Este o plasă de siguranță, nu o capacitate: un server care se sprijină continuu pe swap răspunde de câteva ori mai lent, chiar și pe un SSD NVMe.

Remediile, de la cel mai simplu la cel mai durabil: reduceți numărul de procese ale aplicației (pm.max_children, workerii Gunicorn), compilați în afara serverului, limitați memoria bazei de date, apoi treceți la o dimensiune superioară.

Alegerea dimensiunii și pregătirea pentru ce urmează

1. Enumerați ce va rula: serverul web, aplicația și numărul ei de procese, baza de date, cache-ul, sarcinile programate.
2. Adunați cu ajutorul tabelului componentelor, adăugați vârful cel mai greu (adesea compilarea), apoi o marjă de 25%.
3. Alegeți dimensiunea care acoperă acest total. Între două dimensiuni vecine, cea mai mică se potrivește atunci când trecerea la dimensiunea superioară se face fără reinstalare.
4. Măsurați după lansare, la vârful zilei, apoi la fiecare etapă de creștere a aplicației.

Memoria nu este singura resursă: procesorul contează pentru ce calculează (compilare, procesare de imagini, rularea unui model AI), discul pentru baza de date și fișiere. Pentru o aplicație web însă, memoria este aproape întotdeauna cea care stabilește dimensiunea.