«Il server è lento, raddoppiamo la RAM» è il riflesso più costoso dell'hosting. A volte è giusto. Spesso però la macchina sta aspettando il disco, o la CPU è al limite, e la memoria nuova resta lì a non fare niente mentre la bolletta raddoppia.
Quindi, prima di parlare di chi ha bisogno di 64 GB, capiamo cosa ti manca davvero. Se cerchi solo i numeri tipici di memoria per tipo di carico, li trovi nella nostra guida precedente Quanta RAM serve a un VPS, formula per i modelli linguistici inclusa. Questo articolo parla di diagnosi: RAM, disco o CPU.
Tre comandi, due minuti
Lanciali sul server lento mentre è lento, non alle quattro del mattino quando non succede niente:
free -m
vmstat 1 10
cat /proc/pressure/cpu /proc/pressure/memory /proc/pressure/io
Ecco come leggerli senza un manuale.
free -m. Ignora la colonna free: Linux riempie apposta la memoria libera con la cache del disco. Guarda available. Se su una macchina da 2 GB segna poche centinaia di megabyte e lo used dello swap continua a crescere, la memoria è al limite.
vmstat 1 10. Quattro colonne raccontano quasi tutto:
| Colonna | Cosa significa | Indica |
|---|---|---|
si / so | pagine in entrata e uscita dallo swap al secondo | RAM |
wa | % di tempo in cui la CPU aspetta il disco | disco |
us + sy | % di tempo in cui la CPU lavora | CPU |
st | % di tempo in cui l'hypervisor ha dato la tua CPU a qualcun altro | CPU (vCPU divisa con altri) |
Qualche valore diverso da zero in si/so ogni tanto è normale. Il vero segnale è uno swap costante, secondo dopo secondo.
/proc/pressure/*. Il più onesto dei tre. Ogni file mostra la quota di tempo in cui i processi sono rimasti fermi in attesa di quella risorsa. some avg60=25.00 su memory significa che nell'ultimo minuto qualcosa ha aspettato la memoria per un quarto del tempo. Il file con i numeri più alti è il tuo collo di bottiglia.
Se è il disco
wa alto, pressione io alta, poco swap. La causa tipica è un database o un'applicazione piena di log che legge più di quanto stia in cache.
Ecco il colpo di scena: più RAM può risolverlo, perché Linux metterà in cache più disco. Se il database pesa 6 GB e la parte calda è di 3 GB, passare da 2 a 8 GB di memoria può far sparire il problema del disco. Ma se il database è di 300 GB e ogni query tocca una parte diversa, nessuna quantità ragionevole di RAM lo metterà in cache. Allora servono indici migliori, query più piccole o un'organizzazione diversa dei dati. Tutte le tariffe qui sono su NVMe, quindi raramente è il disco in sé a essere lento. Lo schema di accesso, di solito, sì.
Se è la CPU
us+sy alti, pressione cpu, niente swap, poca attesa del disco. Compressione, build, codifica video, elaborazione di immagini, calcoli crittografici. Più memoria non aiuta per niente.
Tieni d'occhio anche st. Su un VPS una vCPU è una fetta del tempo di un core fisico, non il core intero: il numero della tariffa è un tetto per i picchi, e un carico pieno prolungato può essere limitato per restare equo verso tutti sulla macchina. Se il tuo lavoro ha bisogno di tutti i core al 100 % per ore, è una questione di carico, e preferiamo dirtelo ora che dopo che hai comprato una tariffa più grande.
Se è davvero la RAM
Swap costante, pressione sulla memoria in aumento, l'OOM killer in dmesg. Ora la domanda è: quanta.
2 GB bastano, spesso per anni, per: uno o pochi bot, una piccola API, una VPN, un sito statico dietro Nginx, qualche scraper in cron, un agente di monitoraggio. Micro offre 2 vCPU, 2 GB e 25 GB a 5 $ al mese in NAT, o 10 $ con il suo IPv4.
4–8 GB sono la via di mezzo comoda: un'applicazione web con il suo database, un piccolo indice di ricerca, automazione del browser headless, un paio di agenti affiancati.
32–64 GB sono per i dati che devono vivere in memoria:
- un database il cui working set occupa decine di gigabyte, perché la cache tenga davvero i dati caldi;
- una grande cache o coda in memoria che non può riversarsi sul disco senza rallentare tutto;
- un indice vettoriale per la ricerca su milioni di frammenti (numeri reali in RAG self-hosted su larga scala);
- l'inferenza su CPU di un modello linguistico di medie dimensioni, i cui pesi devono stare nella RAM;
- consolidamento: dieci servizi che prima vivevano su dieci server piccoli.
È a questo che serve Pro-64: 12 vCPU, 64 GB di RAM, 600 GB di NVMe e un IPv4 dedicato a 70 $ al mese. I gradini intermedi sono Pro-32 a 40 $ e Pro-48 a 55 $; sopra, Pro-80 a 90 $. La disponibilità delle località per le tariffe Pro si vede al momento dell'ordine.
Dove una macchina grande non va bene
Tre casi in cui 64 GB è la risposta sbagliata, anche se puoi permettertelo.
Il lavoro su GPU. Nessuna di queste tariffe ha una GPU. Se il tuo modello ne ha bisogno per l'addestramento o per un'inferenza veloce, una macchina CPU con tanta RAM lo farà girare, lentamente, e pagherai la pazienza.
I lavori a CPU piena prolungata. Come sopra: le vCPU sono capacità per i picchi. Dodici al 100 % giorno e notte non sono ciò per cui è fatto un VPS.
E il «non si sa mai». Se i tre comandi non mostrano pressione sulla memoria, i 60 GB in più fanno da cache a file che non leggi. Parti più piccolo. Passare a una tariffa più grande dello stesso tipo di rete aggiunge vCPU, RAM e disco sul posto, con un riavvio, come spiegato in Cambiare tariffa. Scendere sul posto non si può, quindi comprare troppo ha un costo reale: per ridurre devi migrare su un nuovo server, e traslocare un VPS senza downtime è una fatica che faresti volentieri a meno di fare.
Se confronti tariffe di provider diversi, come leggere le specifiche di un VPS spiega cosa promettono davvero i numeri di vCPU, disco e porta.
Commenti
Ancora nessun commento. Sii il primo.