Quanta RAM servirà davvero per i server e i VPS nel 2025?

Il dimensionamento della RAM è un calcolo basato sul carico di lavoro, non un benchmark. Se si spende troppo, si paga per capacità inutilizzata. Se si spende troppo poco, i processi vengono interrotti, il database opera dal disco anziché dalla memoria o i container subiscono limitazioni di velocità. Questa guida fornisce intervalli concreti di RAM per i carichi di lavoro che riscontriamo più spesso (web hosting, database, virtualizzazione, container, inferenza AI e server di gioco), oltre alle regole da seguire quando si deve dimensionare la RAM per qualcosa che non è presente nell’elenco.

Cosa fa la RAM in un server

La RAM contiene tutto ciò su cui il server sta attivamente lavorando. La memoria di processo per i server web, i motori di database e i daemon in background. La cache delle pagine a livello di sistema operativo e i buffer di I/O del disco. La memoria di runtime per le applicazioni e i container. E i blocchi di memoria assegnati alle macchine virtuali o ai carichi di lavoro dei container.

Ciò che distingue il dimensionamento della RAM da quello della CPU è la modalità di guasto. Se si esaurisce la CPU, i processi rallentano. Se si esaurisce la RAM, il kernel ricorre allo swap (lento) oppure l’OOM killer sceglie una vittima e la termina. La prima opzione è sgradevole. La seconda comporta la perdita di dati. Prevedere un margine nella RAM non è un optional, è ciò che impedisce il collasso del sistema sotto carico.

RAM in base al carico di lavoro

Server web e applicativi

• Stack LAMP o LEMP leggero: da 1 a 2 GB
• WordPress o CMS con caching (ad es. Redis): da 2 a 4 GB
• E-commerce (Magento, WooCommerce): da 4 a 8 GB
• Applicazioni Node.js, Django o Rails: da 2 a 6 GB

I livelli di caching come Redis o Varnish richiedono RAM dedicata oltre a quella di base dell’applicazione. I worker PHP-FPM, le connessioni al database e i proxy inversi consumano tutti memoria in modo concorrente, quindi il dato che conta è il parallelismo di picco, non l’impronta a riposo.

Server di database (SQL e NoSQL)

• MySQL o PostgreSQL (piccoli): da 4 a 8 GB
• MySQL o PostgreSQL (di grandi dimensioni o ad alto traffico): da 16 a 64 GB
• MongoDB o Redis (orientati alla memoria): da 32 a 128 GB o più
• Nodi Elasticsearch o OpenSearch: da 32 a 128 GB per nodo

L'obiettivo è mantenere in RAM il working set, gli indici e le righe a cui si accede frequentemente. Non appena uno qualsiasi di questi elementi viene trasferito su disco, la latenza aumenta di diversi ordini di grandezza, indipendentemente dalla velocità dell'SSD.

Host di virtualizzazione (Proxmox, VMware, Hyper-V)

• Macchine virtuali Linux leggere: da 2 a 4 GB per macchina virtuale
• Macchine virtuali Windows: da 8 a 12 GB per macchina virtuale
• Pannelli di hosting (cPanel, Plesk, DirectAdmin): da 4 a 8 GB per istanza
• Host di container KVM o LXC: da 32 a 128 GB o più

Riservare sempre da 4 a 8 GB per il sistema operativo host stesso, oltre alle allocazioni per gli ospiti. I container utilizzano meno RAM per carico di lavoro rispetto alle VM complete, ma scalano in modo diverso, quindi pianificare in base alla densità e al margine di picco piuttosto che alle dimensioni per singolo container. Se l’host utilizza ZFS, tenere conto anche dell’ARC, che per impostazione predefinita occuperà silenziosamente fino alla metà della RAM di sistema e entrerà in competizione con le allocazioni degli ospiti (la nostra guida all’ottimizzazione dell’ARC di ZFS illustra i limiti corretti per i carichi di lavoro dell’hypervisor).

Contenitori e microservizi (Docker, Kubernetes)

• Stack Docker semplici (web, app, DB): da 8 a 16 GB
• Nodi periferici di Docker Swarm o K3s: da 16 a 32 GB
• Nodi di lavoro Kubernetes: da 32 a 128 GB
• Runner CI/CD e agenti di build (GitLab, Jenkins): da 8 a 32 GB per runner

Prestare attenzione alle perdite di memoria nei container a esecuzione prolungata. I carichi di lavoro basati su JVM come Kafka ed Elasticsearch richiedono valori di riferimento più elevati perché l’heap si espande a piacimento, raggiungendo spesso dimensioni superiori al previsto.

Inferenza AI e ML

• Modelli piccoli (BERT quantizzato, Llama 7B): da 16 a 32 GB
• Modelli medi (da 13B a 30B, quantizzati): da 64 a 128 GB
• Modelli di grandi dimensioni (40B+ o modelli di fascia media non quantizzati): da 128 a 512 GB o più
• Inferenza supportata da GPU (Stable Diffusion, Whisper): da 32 a 128 GB a seconda dell’offload

La quantizzazione sposta il carico sulla memoria dalla GPU alla RAM della CPU, quindi le specifiche di sistema cambiano in modo significativo a seconda che si utilizzi fp16 sulla GPU o 4 bit sulla CPU. Anche la dimensione del batch e la lunghezza del prompt fanno aumentare questi valori. La nostra guida all’hosting dell’inferenza AI approfondisce l’abbinamento tra hardware e dimensioni del modello.

Server di gioco

• Minecraft (versione base): da 2 a 4 GB
• Minecraft (modificato): da 6 a 16 GB
• Rust, ARK o 7 Days to Die: da 8 a 16 GB
• Nodi di hosting multi-istanza: da 32 a 64 GB

Carichi di lavoro specializzati

• Transcodifica video (FFmpeg, Plex): da 16 a 64 GB
• Server di backup o snapshot: da 8 a 16 GB, di più se utilizzano motori di deduplicazione
• Firewall o IDS (pfSense, Suricata): da 2 a 8 GB, di più per NetFlow o la registrazione completa dei pacchetti

Non fare affidamento sulla memoria di swap

La memoria swap è da 10 a 100 volte più lenta della RAM. Esiste come rete di sicurezza affinché il kernel abbia uno spazio dove ricorrere in caso di picchi di pressione sulla memoria, non come un modo per estendere la memoria utilizzabile. Se un server ricorre alla memoria swap sotto carico normale, significa che è sottodimensionato, punto e basta. L’articolo «Come interagiscono lo swap di Linux, l’OOM killer e i cgroups» illustra in dettaglio le modalità di guasto.

Come dimensionare accuratamente la RAM

1. Misurate i picchi, non la media. Utilizzate htop, free -m, vmstat 1o le metriche di Kubernetes per individuare il picco di utilizzo nell’arco di un ciclo completo di traffico. I picchi giornalieri, i batch settimanali e i cicli di fatturazione mensili sono tutti fattori rilevanti.
2. Aggiungete un margine per la crescita: dal 20% al 50% per il ridimensionamento delle applicazioni. Per i database, scalate la memoria in base alle dimensioni del set di dati, non alla frequenza delle richieste. Per le piattaforme multi-tenant, calcolate l’impronta per cliente e moltiplicatela.
3. Pianificate in base alla modalità di guasto che potete tollerare. Una replica di lettura a corto di RAM subisce un degrado delle prestazioni. Un database primario a corto di RAM corrompe le query e può causare il crash delle applicazioni. Investite la RAM dove l’impatto è maggiore.

La RAM è la specifica in cui rimanere a corto di memoria danneggia più che andare in eccesso. Aggiungere memoria non renderà più veloce un’applicazione limitata dalla CPU, ma operare con risorse troppo ridotte compromette la stabilità. Dimensionate in base al monitoraggio reale e ai picchi testati, poi lasciate un margine.

FDC offre server dedicati e VPS con configurazioni ad alta RAM e larghezza di banda illimitata in diverse regioni.