PostgreSQL su un VPS: quanta RAM serve davvero e i parametri da cambiare subito

Chi installa PostgreSQL su un VPS con apt install postgresql si ritrova un database configurato per girare ovunque, anche su una macchina con 512MB di RAM. Il risultato: su un VPS da 4 o 8 GB il motore lascia sul tavolo la maggior parte della memoria disponibile. Questa guida riprende i parametri che contano, con i valori di partenza per 2, 4 e 8 GB di RAM.

Installazione su Ubuntu 24.04

Il pacchetto di sistema basta per iniziare:

sudo apt update
sudo apt install postgresql

Per una versione specifica e aggiornamenti dedicati, il progetto PostgreSQL mette a disposizione un repository apt separato. Come indicato sulla pagina ufficiale dei download per Ubuntu, per installare PostgreSQL su Ubuntu si usa il comando apt install postgresql, e il repository Apt supporta tra le altre la distribuzione noble (24.04, LTS). Per installare una versione precisa dal repository PGDG:

sudo apt install -y postgresql-common
sudo /usr/share/postgresql-common/pgdg/apt.postgresql.org.sh
sudo apt install postgresql-18

Il file di configurazione su Ubuntu si trova in /etc/postgresql/<versione>/main/postgresql.conf.

Perché i default non vanno bene su un VPS dedicato

La documentazione ufficiale di PostgreSQL è esplicita sui valori di fabbrica. Per shared_buffers: Sets the amount of memory the database server uses for shared memory buffers. The default is typically 128 megabytes (128MB), but might be less if your kernel settings will not support it. However, settings significantly higher than the minimum are usually needed for good performance.

Per work_mem: Sets the base maximum amount of memory to be used by a query operation (such as a sort or hash table) before writing to temporary disk files. The default value is four megabytes (4MB).

Per maintenance_work_mem: Specifies the maximum amount of memory to be used by maintenance operations, such as VACUUM, CREATE INDEX, and ALTER TABLE ADD FOREIGN KEY. It defaults to 64 megabytes (64MB).

Per max_connections, la pagina ufficiale sulle connessioni riporta: "The default is typically 100 connections, but might be less if your kernel settings will not support it".

La stessa documentazione dà l'indicazione di base per dimensionare shared_buffers: If you have a dedicated database server with 1GB or more of RAM, a reasonable starting value for shared_buffers is 25% of the memory in your system. E aggiunge un limite superiore: oltre quella soglia PostgreSQL continua comunque ad appoggiarsi alla cache del sistema operativo, per cui raramente conviene salire oltre il 40% della RAM totale a shared_buffers, come spiegato nello stesso capitolo della guida (sezione 19.4.1 "Memory").

Valori di partenza per 2, 4 e 8 GB di RAM

Questi valori seguono la logica di PGTune, lo strumento che genera configurazioni di partenza in base all'hardware: è un tool web-based che genera impostazioni consigliate per PostgreSQL in base a hardware e workload, producendo un postgresql.conf pronto con parametri come shared_buffers per la cache dei dati. Chi vuole generare il file completo (incluso effective_cache_size, wal_buffers, max_wal_size) può farlo su pgtune.leopard.in.ua indicando RAM, numero di CPU e tipo di storage del VPS; qui riportiamo i quattro parametri che cambiano quasi sempre nel primo giorno di esercizio, con la logica usata per calcolarli (25% della RAM per shared_buffers, quota residua per work_mem in base a max_connections stimati).

RAM VPS	shared_buffers	work_mem	maintenance_work_mem	max_connections
2 GB	512MB	4MB	128MB	50
4 GB	1GB	8MB	256MB	75
8 GB	2GB	16MB	512MB	100

Note pratiche su questi numeri:

• shared_buffers resta al 25% della RAM totale su tutti e tre i profili, in linea con l'indicazione ufficiale per server dedicati con 1GB o più. Su un VPS condiviso con altri servizi (nginx, redis, applicazione), vale la pena scendere al 15-20% per lasciare margine al resto dello stack.
• work_mem è un valore per operazione, non per connessione: una query con più sort o hash concorrenti può moltiplicarlo. Su VPS con poca RAM meglio restare bassi (4-8MB) e alzarlo solo se nei log compaiono righe "temporary file" ripetute.
• maintenance_work_mem incide solo su VACUUM, CREATE INDEX e dump/restore: può essere più alto di work_mem senza rischi, perché since only one of these operations can be executed at a time by a database session, and an installation normally doesn't have many of them running concurrently, it's safe to set this value significantly larger than work_mem.
• max_connections più basso di 100 non è un limite stretto: con poca RAM conviene tenerlo contenuto e usare un connection pooler (pgbouncer) davanti al database, piuttosto che alzarlo e rischiare di esaurire la memoria quando tutte le connessioni sono attive insieme.

Come applicare le modifiche

Due strade equivalenti. La prima, editando il file:

sudo nano /etc/postgresql/18/main/postgresql.conf

e modificando le righe shared_buffers, work_mem, maintenance_work_mem, max_connections con i valori scelti, poi:

sudo systemctl restart postgresql

La seconda, da riga di comando SQL, con ALTER SYSTEM, utile perché non richiede di cercare la riga nel file: ALTER SYSTEM is used for changing server configuration parameters across the entire database cluster. ALTER SYSTEM writes the given parameter setting to the postgresql.auto.conf file, which is read in addition to postgresql.conf.

sudo -u postgres psql -c "ALTER SYSTEM SET shared_buffers = '1GB';"
sudo -u postgres psql -c "ALTER SYSTEM SET work_mem = '8MB';"
sudo -u postgres psql -c "ALTER SYSTEM SET maintenance_work_mem = '256MB';"
sudo -u postgres psql -c "ALTER SYSTEM SET max_connections = 75;"
sudo systemctl restart postgresql

shared_buffers e max_connections sono parametri "static": richiedono il riavvio del servizio, non basta il reload. work_mem e maintenance_work_mem si applicano anche con un semplice reload (sudo systemctl reload postgresql o SELECT pg_reload_conf();), ma dopo una serie di modifiche conviene comunque riavviare per essere sicuri che tutto sia allineato.

Verificare che le modifiche siano state applicate

Dopo il riavvio, da psql:

sudo -u postgres psql -c "SHOW shared_buffers;"
sudo -u postgres psql -c "SHOW work_mem;"
sudo -u postgres psql -c "SHOW maintenance_work_mem;"
sudo -u postgres psql -c "SHOW max_connections;"

Per un controllo in un colpo solo, con i valori sorgente (file vs default vs sessione):

sudo -u postgres psql -c "SELECT name, setting, unit, source FROM pg_settings WHERE name IN ('shared_buffers','work_mem','maintenance_work_mem','max_connections');"

La colonna source deve riportare configuration file (se modificato nel .conf) o restare coerente con postgresql.auto.conf se si è usato ALTER SYSTEM. Se compare ancora default, la modifica non è stata letta: verificare di aver riavviato il servizio giusto (systemctl status postgresql@18-main su installazioni multi-versione) e di non avere un secondo file di configurazione che sovrascrive il primo.

Un avvertimento sui numeri di questa tabella

Questi valori sono un punto di partenza, non una configurazione definitiva. Vanno verificati con il carico reale: se nei log di PostgreSQL compaiono righe temporary file ripetute, work_mem va alzato; se top mostra swap attivo dopo il riavvio, shared_buffers è troppo alto per la RAM realmente libera sul VPS (un VPS con pannello di controllo, PHP-FPM e Redis attivi ha molta meno RAM libera di un server dedicato solo al database). Per un tuning più fine, con effective_cache_size, wal_buffers e checkpoint_completion_target, lo strumento di riferimento resta PGTune, da usare inserendo i dati reali del VPS e non quelli di un server dedicato.