Dimensionare un server cloud: quanta CPU, RAM e SSD serve?
Dimensionare un server cloud parte dal carico di lavoro, non dall'hardware. Questa guida offre intervalli iniziali di vCPU, RAM e disco per i carichi più comuni, li associa ai preset Small, Medium e Large della pagina server cloud DCXV e mostra come verificare il risultato dopo il deploy con pochi comandi. Tutti gli intervalli qui sotto sono stime e punti di partenza, non misure. Il tuo codice, il tuo traffico e i tuoi dati decidono i numeri reali.
Parti dal carico di lavoro
Annota quattro fatti prima di aprire un configuratore: cosa gira (web server, database, applicazione Windows), quante persone o richieste arrivano nell'ora di punta, quanti dati hai oggi e quanto in fretta crescono.
Poi individua la risorsa che si esaurisce per prima. Un negozio PHP finisce di solito la RAM prima della CPU. Un server di build finisce la CPU. Un database finisce la RAM, poi la velocità del disco. Dimensiona per quel collo di bottiglia e lascia che il resto segua.
Intervalli iniziali per carico di lavoro
I preset: Small ha 2 vCPU, 4 GB di RAM, 40 GB NVMe da EUR 15.00/mese. Medium ha 4 vCPU, 8 GB, 80 GB NVMe da EUR 18.43/mese. Large ha 8 vCPU, 16 GB, 160 GB NVMe da EUR 36.88/mese. Prezzi verificati nel 2026-10, ogni prezzo include un backup settimanale. Prima di confrontare, vedi cosa determina il prezzo.
| Carico di lavoro | Intervallo iniziale (stima) | Preset più vicino |
|---|---|---|
| Dev/test, VPN, monitoraggio, servizi di utilità | 1-2 vCPU, 1-4 GB RAM, 20-40 GB disco | Small |
| Piccolo sito o blog, poco traffico | 2 vCPU, 2-4 GB RAM, 20-40 GB disco | Small |
| Negozio online, API o MVP SaaS | 2-4 vCPU, 4-8 GB RAM, 40-80 GB disco | Medium |
| Applicazione con database proprio | 4-8 vCPU, 8-16 GB RAM, 80-160 GB disco | Medium o Large |
| Applicazione aziendale Windows/RDP | Prima la formula del produttore. M.E.Doc terminal: CPU = 4 + utenti, RAM = utenti x 2 GB + 4 GB | Large fino a 4 utenti, oltre su misura |
Ipotesi: Linux, un'applicazione principale, traffico normale con picchi occasionali, niente GPU né pesanti elaborazioni batch. Per la riga Windows la formula del produttore prevale su qualsiasi tabella: è un requisito, non una stima, e cambia con il tipo di deploy, quindi leggi la pagina attuale del produttore. Se i tuoi numeri cadono tra due preset o oltre Large, crea una configurazione su misura nel calcolatore della pagina dei server cloud.
Un budget di RAM per un piccolo negozio
Ecco un budget illustrativo per un negozio online su un server. Le cifre sono ipotesi, non misure.
- Sistema operativo e servizi - 0.5 GB.
- PHP-FPM - 10 worker x 100 MB = 1 GB.
- Buffer del database - 2 GB.
- Cache Redis - 0.5 GB.
- Cache dei file e picchi - 1 GB.
Il totale è circa 5 GB. Un server da 4 GB userebbe lo swap sotto carico. Uno da 8 GB lascia liberi circa 3 GB, quasi un terzo. Sostituisci ogni riga con i tuoi numeri quando il negozio è in funzione: i comandi qui sotto li mostrano.
Margine, sistema operativo e archiviazione
- CPU - punta a un carico sostenuto sotto il 70% circa nell'ora di punta, così un picco non accoda le richieste.
- RAM - mantieni disponibile il 20-25%. Uno swap costante significa che il server è troppo piccolo.
- Disco - resta sotto l'80% di riempimento. Database, log e aggiornamenti crescono più in fretta del previsto.
- Sistema operativo - un Linux minimale richiede poche centinaia di MB. Windows Server con desktop richiede alcuni GB prima che la tua applicazione parta (stima).
La capacità di backup non è archiviazione di produzione
Il prezzo di ogni preset include un backup settimanale. È una copia di sicurezza del disco del server, non spazio extra per i tuoi file. Non contarla quando dimensioni il disco e non pensare di tenere archivi, media o dump "nel backup". I dati di produzione stanno sul disco del server, quindi dimensionalo per dati, crescita e margine. Prima di una modifica rischiosa aggiungi uno snapshot: vedi snapshot delle VM cloud.
Misura dopo il deploy
Misura in una normale ora di punta e ancora durante un picco. Su Debian o Ubuntu iostat arriva dal pacchetto sysstat. Per campionare la RAM per un'intera settimana e ottenere la dimensione giusta, usa lo script ramuse.py di misurare la RAM che usi davvero nella scarsità di DRAM del 2026.
top -b -n 1 | head -n 15
free -h
vmstat 5 5
df -h
sudo apt install sysstat
iostat -xz 5 3
ps -eo pid,comm,%mem,%cpu --sort=-%mem \
| head -n 8
sudo du -xh --max-depth=1 /var \
| sort -h \
| tail -n 8
Come leggere l'output:
- top - confronta il load average con il numero di vCPU. Un carico a lungo superiore alle vCPU indica pressione sulla CPU. Il valore
stè tempo di CPU sottratto dall'host. - free - leggi la colonna
available, nonfree. - vmstat - valori diversi da zero in
siesoindicano swap. - iostat -
%utilalto eawaitin crescita indicano che il collo di bottiglia è il disco.
Per un'applicazione intera e non un solo carico, segui l'esempio svolto in Server cloud per SaaS: dimensionare CPU, RAM, NVMe e backup: un budget di memoria per container, un test di carico k6 e una scheda stampabile.
Scegli e verifica
Prendi il preset più vicino dalla tabella e fallo girare sotto carico reale. Un breve test è il modo onesto per verificare una stima: vedi la checklist della prova. Scrivi a sales@dcxv.com per chiedere una breve prova; è a discrezione di DCXV e non è garantita. Non sei sicuro dei numeri? Invia i requisiti a sales@dcxv.com e un ingegnere li esaminerà, oppure apri la pagina dei server cloud e scegli un preset.
