Quanta RAM serve per un VPS: la regola, uso per uso

La regola: sommare ciò che resta in memoria

Un server non consuma memoria «in generale»: ogni programma in esecuzione ne occupa una parte, finché resta in esecuzione. Il calcolo parte quindi dall'elenco dei processi sempre presenti, poi aggiunge il picco e un margine:

Memoria da prevedere = (sistema + servizi permanenti + picco delle operazioni occasionali) × 1,25

• Il sistema: una distribuzione Linux minima (Debian, Ubuntu) occupa tra 150 e 300 MB circa una volta avviata, accesso SSH e registrazione dei log compresi.
• I servizi permanenti: server web, processi dell'applicazione, database, cache, coda di job. Il loro consumo dipende dalla tecnologia, come spiega la sezione seguente.
• Il picco: ciò che si aggiunge in certi momenti, come la compilazione di un'applicazione, un backup, un'importazione, un'operazione pianificata pesante. Un server dimensionato sulla sua media cede proprio in quei momenti.
• Il margine: il 25% in più rispetto al totale, per la crescita dei dati e del traffico. Non resta inutilizzato: Linux usa la memoria libera come cache dei file, e questo accelera il database.

Quanto consuma ogni componente

Gli ordini di grandezza qui sotto valgono per un'applicazione di dimensioni comuni, misurata in produzione. Danno un punto di partenza; la misura sulla vostra applicazione, descritta più avanti, ha sempre l'ultima parola.

Un picco ricorre spesso con le applicazioni JavaScript: la compilazione. npm run build su un progetto Next.js, Nuxt o Angular richiede comunemente da 1 a 2 GB da solo, per qualche minuto, in aggiunta a ciò che è già in esecuzione. Compilare sul server significa dimensionare per quel picco; compilare sul vostro computer o nella vostra integrazione continua e caricare solo il risultato significa evitarlo.

Stesso ragionamento per i container Docker: ogni container è un insieme di processi come gli altri, e il demone Docker aggiunge il proprio consumo. docker stats mostra quanto occupa ciascuno.

Profili tipo

Questi profili sommano i componenti precedenti, picco e margine compresi. Presuppongono un'applicazione di dimensioni comuni e il traffico di un lancio; un database voluminoso o un traffico sostenuto spostano l'asticella verso l'alto.

Un'applicazione che chiama un modello di IA tramite API (OpenAI, Anthropic, Mistral) si dimensiona come qualsiasi applicazione web: il modello gira presso il suo fornitore, e il vostro server attende la risposta. È l'esecuzione del modello sul server stesso a cambiare la scala.

Misurare su un server in funzione

Su un server in servizio, la misura sostituisce la stima. Tre comandi dicono a che punto siete:

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

• free -h: leggete la colonna available, la memoria realmente disponibile per avviare nuovi programmi. La colonna free è quasi sempre bassa, ed è normale: Linux riempie la memoria inutilizzata con la cache dei file (buff/cache), che restituisce appena un programma ne ha bisogno.
• ps aux --sort=-rss: i processi ordinati per memoria occupata (colonna RSS, in kilobyte). È qui che si vede quanto pesa ogni worker PHP o Node.js.
• vmstat 5 5: cinque rilevazioni a cinque secondi di distanza. Valori diversi da zero nelle colonne si e so, rilevazione dopo rilevazione, indicano un server che scambia pagine con lo swap: gli manca memoria.

Misurate nel momento più carico della giornata, e durante le operazioni occasionali: compilazione, backup, importazione. È il picco che conta.

Quando la memoria manca

Un server a corto di memoria non rallenta in modo progressivo. Quando non c'è più nulla da liberare, il kernel Linux fa intervenire l'OOM killer (out of memory): sceglie un processo, in genere quello che occupa più memoria, e lo termina di colpo. Su un server applicativo, spesso è il database.

I sintomi: errori 502 o 503 a tratti, un servizio che si riavvia senza motivo apparente, una compilazione che si interrompe con Killed. I log lo confermano:

journalctl -k | grep -i "out of memory"
systemctl status nome-del-servizio

Nell'output di systemctl status, la dicitura Failed with result 'oom-kill' indica un servizio fermato per mancanza di memoria.

Lo swap, quando il server ne dispone, ritarda quel momento spostando su disco la memoria meno usata. Fa da rete di sicurezza, non da capacità: un server che si appoggia allo swap in continuazione risponde parecchie volte più lentamente, anche su un SSD NVMe.

I rimedi, dal più semplice al più duraturo: ridurre il numero di processi dell'applicazione (pm.max_children, worker Gunicorn), compilare fuori dal server, limitare la memoria del database, poi passare a una taglia superiore.

Scegliere la taglia, e prevedere il seguito

1. Elencate ciò che girerà: server web, applicazione e numero di processi, database, cache, operazioni pianificate.
2. Sommate con la tabella dei componenti, aggiungete il picco più pesante (spesso la compilazione), poi il 25% di margine.
3. Scegliete la taglia che copre questo totale. Tra due taglie vicine, la più piccola va bene a patto che il passaggio alla taglia superiore avvenga senza reinstallare.
4. Misurate dopo la messa online, al picco della giornata, poi a ogni fase di crescita dell'applicazione.

La memoria non è l'unica risorsa: il processore conta per ciò che calcola (compilazione, elaborazione di immagini, esecuzione di un modello di IA), il disco per il database e i file. Per un'applicazione web, però, è quasi sempre la memoria a decidere la taglia.