Immagina di essere il capitano di una nave che naviga nell’oceano dei dati. Non vuoi solo che la nave vada avanti. Vuoi essere sicuro che non finisca contro l’iceberg delle query lente, che non ti becchi una tempesta improvvisa di lock e che la nave non affondi per troppi connection. Il monitoring del database è il tuo radar, barometro ed ecoscandaglio che ti aiuta a evitare iceberg, tempeste e panico.
Perché e come monitorare un database
Il monitoring ti aiuta a mantenere il database stabile e a notare i problemi prima che diventino grossi. Immagina che invece di vedere il servizio crashare all’improvviso, ricevi un segnale in anticipo: “Ehi, questa query gira da 30 secondi, c’è qualcosa che non va”. Sai già dove c’è il collo di bottiglia, chi tiene il lock e in che punto il database rischia di soffocare per mancanza di risorse.
Ecco a cosa dovresti fare attenzione:
Attività di query e transazioni. Tieni d’occhio il flusso delle query come un dispatcher controlla il traffico a un incrocio. Quali comandi SQL rallentano gli altri? Chi sta caricando di più il database? Queste risposte ti danno la possibilità di ottimizzare senza panico.
Utilizzo delle risorse. CPU, RAM e spazio disco sono come il carburante e lo scafo della nave. Se una risorsa “fa acqua” o è sovraccarica, tutta la nave si ferma. Il monitoring ti mostra dove c’è overload e ti permette di ridistribuire il carico.
Performance delle query. Alcune query SQL sono come passeggeri capricciosi: chiedono troppo, rallentano gli altri e si lamentano sempre. Il monitoring ti fa vedere chi sono i più “affamati” — così puoi indicizzare, riscrivere o sostituire.
Lock e conflitti. A volte le query vanno in conflitto: una tiene una risorsa, l’altra aspetta. È come se uno tiene la porta da una parte e l’altro la tira dall’altra. Il monitoring di questi lock ti permette di intervenire in tempo e togliere la tensione.
Un buon monitoring non ti dice solo che il database è “vivo”. Ti suggerisce dove la sua vita potrebbe andare in crisi — e ti dà il tempo di sistemare tutto prima che i problemi diventino reali.
Metriche chiave per il monitoring di PostgreSQL
Per capire lo stato del tuo database, devi sapere cosa guardare. Queste metriche sono il “battito” e la “pressione” del database. Ecco i parametri principali:
Numero di connection attive.
Quanti utenti sono collegati ora? Stanno cercando di rompere il database con query a caso? Per esempio,
pg_stat_activity, di cui parleremo nelle prossime lezioni, mostra l’attività attuale.Tempo di esecuzione delle query.
Quali query girano più veloci? E al contrario, quali query pensano di essere già in pensione?
Utilizzo degli indici.
Se hai indici ma non li usi, qualcosa non va. Lo controlliamo con
pg_stat_user_indexes.Livello di lock e conflitti.
Molto usato per prevenire i “Deadlock” (lock reciproci).
Carico CPU e uso della memoria.
Ad esempio, quante risorse del server si “mangia” PostgreSQL?
Come si vede nella pratica?
Diamo un’occhiata a un esempio reale. Ecco una query semplice che ti fa vedere la dimensione di un database specifico:
SELECT pg_size_pretty(pg_database_size('nome_del_tuo_database')) AS database_size;
Questa query ti restituisce la dimensione del database in formato leggibile — tipo 243 MB o 1.2 GB. Utile quando vuoi capire al volo quanto è cresciuto il database di recente.
Se vuoi vedere le dimensioni di tutti i database insieme — senza doverli specificare uno per uno — puoi usare questa variante:
SELECT datname, pg_size_pretty(pg_database_size(datname)) AS size
FROM pg_database;
Così hai una panoramica di tutti i database sul server — comodo per l’admin che controlla l’uso del disco e vuole beccare i “più affamati” prima di ricevere una mail dall’hosting: “Stai finendo lo spazio”.
GO TO FULL VERSION