Guida al dimensionamento dei VPS per scegliere il server più adatto
Pubblicato il 20 ottobre 2026
Di solito, se un VPS è lento, non è perché gli mancano tutte le risorse. Gli manca una risorsa proprio nel momento sbagliato: memoria durante un picco di traffico, CPU durante la generazione di report, I/O del disco durante i backup o larghezza di banda durante una campagna intensa. Questa guida al dimensionamento dei VPS ti aiuta a individuare il fabbisogno reale prima di pagare per capacità che non userai o, peggio ancora, di distribuire un server che va in affanno già dal primo lunedì di intenso utilizzo.
L'obiettivo non è scegliere il piano più grande. È garantire a ogni carico di lavoro risorse sufficienti per funzionare normalmente, gestire i picchi prevedibili e riprendersi senza problemi quando qualcosa richiede più tempo del previsto. Un VPS dimensionato correttamente dovrebbe funzionare senza affanni con un carico normale e avere comunque un margine misurabile.
Parti dal carico di lavoro, non dal piano
Il dimensionamento parte da ciò che il server dovrà fare concretamente. Un sito vetrina, un negozio WooCommerce, un'applicazione SaaS, un ambiente di sviluppo e un server di agenzia che ospita diversi siti dei clienti possono avere un numero di visitatori simile, ma richiedere risorse molto diverse.
Per prima cosa, individua i servizi che condividono il VPS. Un server web, un database, processi PHP, una cache, un relay di posta elettronica, processi in background, container Docker, agenti di monitoraggio e attività di backup consumano risorse secondo modalità diverse. Il database potrebbe aver bisogno di memoria e di un accesso rapido al disco, mentre un worker di coda potrebbe aver bisogno di CPU solo per pochi minuti ogni ora.
Considera anche i momenti più importanti. L'utilizzo medio è utile, ma è quello di picco a determinare se i clienti usufruiranno di un servizio reattivo o visualizzeranno una pagina di timeout. Un negozio online potrebbe essere tranquillo durante la notte e poi ricevere un'ondata di ordini dopo una campagna email. Una piattaforma SaaS potrebbe funzionare senza problemi tutto il giorno, fino all'avvio delle importazioni pianificate a mezzanotte. I log raccontano la stessa storia: le medie possono essere rassicuranti, i picchi sono più sinceri.
Se stai sostituendo un server esistente, raccogli almeno una o due settimane di misurazioni prima di scegliere il nuovo dimensionamento. Esamina l'utilizzo della CPU, la memoria disponibile, l'attività di swap, lo spazio su disco, l'attesa I/O del disco, il trasferimento di rete e il tempo di risposta dell'applicazione. Se possibile, includi sia la normale attività aziendale sia un periodo di picco noto.
Le quattro risorse che determinano il dimensionamento del VPS
CPU: potenza di elaborazione per i carichi attivi
Il numero di core della CPU determina quanto lavoro attivo il tuo VPS può completare contemporaneamente. I siti dinamici usano la CPU per PHP, Node.js, Python, Java, richieste API, elaborazione delle immagini, indicizzazione delle ricerche, crittografia e processi pianificati. Un numero maggiore di core è particolarmente utile quando più richieste o attività in background devono essere eseguite contemporaneamente.
Per un piccolo sito di contenuti con caching, potrebbero bastare da 1 a 2 vCPU. Un sito WordPress o WooCommerce molto frequentato, un piccolo stack applicativo o diversi siti con poco traffico spesso funzionano meglio a partire da 2 a 4 vCPU. Le applicazioni con importazioni regolari, conversione di immagini, processi CI o più container potrebbero aver bisogno di almeno 4 vCPU, anche con un traffico modesto.
Fai attenzione all'utilizzo sostenuto della CPU, non ai picchi brevi. Un server che raggiunge il 90% di utilizzo della CPU per pochi secondi durante una distribuzione non è necessariamente sottodimensionato. Un server che supera circa il 70% durante i normali periodi di picco ha meno margine per gestire aumenti di traffico, scansioni di sicurezza e manutenzione ordinaria.
Il dimensionamento della CPU dipende anche dalla progettazione del software. Un caching aggressivo delle pagine può ridurre notevolmente il fabbisogno di CPU. Le query del database non ottimizzate possono consumare tutti i core disponibili con una determinazione ammirevole. Aggiungere CPU può essere d'aiuto, ma non dovrebbe sostituire la correzione di un problema evitabile dell'applicazione.
RAM: la risorsa che previene i problemi
La memoria è spesso la prima risorsa da dimensionare con attenzione. La RAM supporta il sistema operativo, i processi web, i buffer del database, la cache, i container e gli strumenti di monitoraggio. Quando la memoria fisica si esaurisce, Linux inizia a usare lo spazio di swap sul disco. Lo swap è utile come margine di sicurezza in caso di emergenza, ma un'attività di swap frequente è un segnale d'allarme, non una strategia per migliorare le prestazioni.
Un server Linux leggero con uno stack web semplice può funzionare con da 1 a 2 GB di RAM. Per un sito web di produzione che usa un database e la cache, un punto di partenza più realistico è da 2 a 4 GB. Negozi, installazioni CMS di dimensioni maggiori, siti di più clienti e server applicativi hanno comunemente bisogno di almeno 4-8 GB, a seconda del numero di worker e dell'attività del database.
Non calcolare il fabbisogno di RAM basandoti solo sulla documentazione dell'applicazione. Considera il comportamento effettivo dei processi. Ad esempio, ogni worker PHP potrebbe usare una quantità significativa di memoria e un aumento dei visitatori simultanei può moltiplicare rapidamente tale consumo. Anche i motori di database usano memoria per mantenere disponibili i dati consultati di frequente, senza doverli rileggere continuamente dal disco.
Un obiettivo pratico è mantenere memoria disponibile durante i picchi di utilizzo ed evitare un uso prolungato dello swap. Se il server ha RAM libera ma i tempi di risposta restano scarsi, prima di aumentare semplicemente la memoria verifica se la CPU è satura, se ci sono problemi di I/O del disco, blocchi del database o ritardi nelle API esterne.
Archiviazione: la capacità è solo metà del discorso
Il dimensionamento dell'archiviazione dipende da due fattori: lo spazio necessario e la velocità di risposta del disco. Un VPS può avere molto spazio libero su disco e comunque funzionare male se il carico di lavoro genera più operazioni su disco di quante il livello di archiviazione sia in grado di gestire.
Calcola lo spazio necessario per il sistema operativo, i file dell'applicazione, i database, i caricamenti, i log, i file temporanei e la conservazione locale dei backup. Poi aggiungi un margine per la crescita. I database crescono gradualmente, finché non smettono di farlo. I file di log possono crescere molto rapidamente in caso di errore dell'applicazione: non è certo il momento ideale per scoprire che il disco è pieno.
Per la maggior parte dei carichi di lavoro di produzione, l'archiviazione basata su SSD o NVMe è una scelta di base sensata. Un'archiviazione veloce è importante per le query del database, le operazioni di checkout di WooCommerce, l'amministrazione del CMS, gli aggiornamenti software e la compressione dei backup. Se l'attesa I/O del disco aumenta nei periodi di picco, il server potrebbe essere in attesa dell'archiviazione anziché essere a corto di CPU.
Evita di conservare il tuo unico backup sullo stesso VPS del servizio attivo. Gli snapshot locali possono velocizzare il ripristino, ma i backup indipendenti proteggono da una gamma più ampia di guasti, tra cui le eliminazioni accidentali e i problemi a livello di server.
Larghezza di banda e trasferimento di rete: misura la direzione del traffico
La larghezza di banda è la velocità della connessione. Il trasferimento è la quantità totale di dati spostati durante un periodo di fatturazione. Entrambi sono importanti, ma risolvono problemi diversi.
Un sito con molti contenuti multimediali, un servizio di download, una piattaforma API o un negozio con immagini dei prodotti di grandi dimensioni può trasferire molti più dati di un sito web testuale con lo stesso numero di visitatori. L'uso di una CDN, l'ottimizzazione delle immagini, il caching del browser e l'archiviazione di oggetti possono ridurre il traffico proveniente dal VPS. Per il traffico delle applicazioni, considera anche i dati in uscita: le risposte API, i backup inviati all'esterno, la replica e le esportazioni del monitoraggio lasciano tutte il server.
La capacità di rete dovrebbe essere sufficiente a gestire i picchi previsti, mentre il limite di trasferimento dovrebbe coprire l'utilizzo mensile con un margine. Se il tuo team marketing sta pianificando un lancio, dimensiona le risorse in base alla campagna prima che inizi. Nemmeno ai server piacciono le sorprese.
Un dimensionamento di base pratico per il VPS
Questi sono punti di partenza, non regole fisse. Il software, il modello di traffico, la configurazione della cache e i requisiti di gestione possono modificare la scelta.
- Un piccolo sito vetrina o un server di sviluppo di solito può funzionare con 1-2 vCPU, 1-2 GB di RAM e 20-40 GB di archiviazione veloce.
- Un sito web aziendale, una piccola installazione CMS o un'applicazione con volumi ridotti funzionano in genere senza problemi con 2 vCPU, 2-4 GB di RAM e 40-80 GB di archiviazione veloce.
- Un CMS molto frequentato, un negozio WooCommerce, un ambiente di hosting per agenzie o un piccolo servizio SaaS richiedono spesso 2-4 vCPU, 4-8 GB di RAM e almeno 80 GB di archiviazione veloce.
- Un'applicazione che usa intensamente il database, un negozio di grandi dimensioni, uno stack containerizzato o un carico di lavoro con elaborazioni regolari in background potrebbe aver bisogno di almeno 4 vCPU, almeno 8 GB di RAM e un'archiviazione scelta appositamente per le prestazioni I/O.
Il dimensionamento iniziale più adatto dovrebbe lasciare un margine di capacità di circa il 25-40% durante i normali picchi di attività. Questo margine non è uno spreco. Offre al servizio spazio per gestire la crescita del traffico, i backup, gli aggiornamenti di sicurezza e quei comportamenti occasionali dell'applicazione che si presentano senza invito.
Verifica dopo la distribuzione
Il dimensionamento non è una decisione da prendere una volta sola. Distribuisci il carico di lavoro, monitoralo e apporta modifiche basandoti sui dati. Gli indicatori più utili sono il carico sostenuto della CPU, la pressione sulla memoria, l'uso dello swap, l'attesa I/O del disco, la crescita dello spazio di archiviazione, l'utilizzo della rete e i tempi di risposta effettivi dell'applicazione.
Le metriche di Prometheus e Grafana sono particolarmente utili per i team che vogliono correlare l'attività dell'infrastruttura con l'esperienza degli utenti. Ad esempio, un picco nei tempi di risposta che coincide con un'attesa I/O elevata indica una causa diversa rispetto a un picco che coincide con l'esaurimento dei worker PHP. Il monitoraggio trasforma il ridimensionamento da un tentativo alla cieca a un'attività operativa controllata.
Per molte aziende, anche il supporto gestito modifica il calcolo. Un team tecnicamente competente potrebbe preferire ottimizzare i worker, la cache, le impostazioni del database e le pianificazioni dei backup prima di passare a un VPS più grande. Su kodu.cloud, questa verifica operativa contribuisce a riportare il servizio alla normalità, invece di considerare ogni avviso una scusa per acquistare un server più potente.
Pianifica la crescita senza pagare per spazio inutilizzato
Scegli un VPS in grado di gestire il carico di picco attuale con un margine, poi verifica che l'aggiornamento di CPU, RAM o archiviazione sia semplice quando i dati lo giustificano. Partire con risorse insufficienti può rendere necessarie migrazioni urgenti. Partire con risorse decisamente eccessive può nascondere codice inefficiente e assorbire il budget senza migliorare l'esperienza dei clienti.
Esamina ogni mese l'andamento delle risorse, soprattutto dopo aver lanciato nuove funzionalità, aggiunto siti di clienti, modificato le politiche di backup o realizzato una campagna marketing di successo. Un server dovrebbe essere potenziato perché il carico di lavoro ha dimostrato di averne bisogno, non perché il nome del piano sembrava rassicurante. Con metriche chiare e un po' di capacità di riserva, puoi riposare mentre l'infrastruttura continua a fare il suo lavoro.
Andres Saar, ingegnere del supporto clienti