«Too many connections» su MySQL e MariaDB: perché capita e cosa cambiare

Verifica rapida (30 secondi)

Prima di tutto va capito se il limite è davvero pieno adesso. Da riga di comando, su qualunque sistema con MySQL o MariaDB:

mysql -u root -p -e "SHOW VARIABLES LIKE 'max_connections'; SHOW STATUS LIKE 'Threads_connected';"

Se Threads_connected è vicino o uguale al valore di max_connections, il limite è saturo adesso. Se invece è molto più basso, l'errore che hai visto in log è stato un picco già passato, e il problema è intermittente: le cause da guardare cambiano, vedi sotto.

Per vedere chi tiene aperte le connessioni:

mysql -u root -p -e "SHOW FULL PROCESSLIST;"

La colonna che conta è Command: se vedi molte righe con Sleep e un Time alto, le connessioni non vengono chiuse dall'applicazione, non è un picco di traffico reale.

Cosa significa l'errore

MySQL e MariaDB accettano un numero massimo di connessioni simultanee, fissato dal parametro max_connections. Quando questo numero viene raggiunto, il server rifiuta le nuove connessioni con l'errore ERROR 1040 (HY000): Too many connections, anche se il database ha ancora CPU e dischi liberi. Il sito non è lento: è il database che chiude la porta a nuovi arrivi.

Le cause, in ordine di frequenza

1. Connessioni persistenti o in sleep lasciate aperte

È la causa più comune su siti con pannello o CMS che aprono una connessione per pagina e non la chiudono subito. Si verifica con SHOW FULL PROCESSLIST come sopra: molte righe Sleep con Time superiore a 60-100 secondi indicano applicazione che non rilascia le connessioni, o un pool mal configurato lato PHP-FPM (connessioni persistenti con mysqli_connect in modalità p:).

Soluzione: disattivare le connessioni persistenti lato applicativo se non gestite da un pool dedicato, e impostare wait_timeout più basso per chiudere le sleep inattive. Su Ubuntu 24.04 con Nginx e PHP-FPM si modifica in /etc/mysql/mysql.conf.d/mysqld.cnf (percorso documentato da MariaDB, vedi sotto) aggiungendo wait_timeout = 60 sotto [mysqld], poi si riavvia con sudo systemctl restart mariadb (o mysql a seconda del pacchetto installato). Su cPanel il file equivalente è /etc/my.cnf, da modificare con WHM > MySQL/MariaDB Configuration oppure a mano, poi service mysql restart. Su Plesk il percorso è lo stesso /etc/my.cnf o /etc/mysql/my.cnf a seconda della distribuzione, gestibile anche da Strumenti e impostazioni > Impostazioni MySQL.

2. max_connections alzato senza guardare la memoria

Qui il rischio è opposto: alzare il numero a caso per "far passare" l'errore, senza calcolare quanta RAM serve, fa sì che il server vada in OOM (out of memory) e il processo MySQL venga ucciso dal kernel, con un danno peggiore del semplice errore 1040.

Si verifica controllando quanta memoria è assegnata per thread. La documentazione ufficiale di MariaDB (mariadb.com/kb/en/mysqld-options/#-max-connections) indica che ogni connessione consuma memoria per thread stack, buffer di sort, join e read, oltre al buffer pool condiviso. Una stima prudente: memoria RAM disponibile per MySQL diviso per circa 12-15 MB a connessione (valore indicativo che varia con sort_buffer_size, join_buffer_size e thread_stack configurati), al netto della RAM riservata a innodb_buffer_pool_size e al sistema operativo.

Esempio: su un server con 4 GB di RAM dedicati al solo MySQL, se 2,5 GB sono assegnati a innodb_buffer_pool_size, restano 1,5 GB per le connessioni: a 12 MB a connessione sono circa 125 connessioni, non le 500 che si leggono spesso impostate a caso in guide generiche.

Soluzione: calcolare il valore con la formula sopra, non copiarlo da un'altra guida. Si imposta nello stesso file mysqld.cnf con max_connections = <valore calcolato> e si riavvia il servizio.

3. Mancanza di un pool di connessioni o di una object cache

Se l'applicazione (CMS, pannello di hosting, e-commerce) apre una connessione nuova per ogni richiesta invece di riusarle, il numero di connessioni simultanee cresce con il traffico in modo lineare, e qualunque valore di max_connections prima o poi si satura nei picchi.

Si verifica controllando se il traffico in Threads_connected segue l'andamento delle visite (picchi che coincidono con gli accessi) e se la cache oggetti del CMS (es. Redis o Memcached per WordPress/WooCommerce) non è attiva: senza cache, ogni pagina rifà query al database invece di leggere dalla cache.

Soluzione strutturale: un pool di connessioni come ProxySQL davanti al database riduce le connessioni reali verso MySQL/MariaDB mantenendole aperte e riutilizzandole, indipendentemente da quante ne apre l'applicazione. In alternativa, o in aggiunta, una object cache (Redis o Memcached) abbatte il numero di query — e quindi di connessioni necessarie — perché le pagine già viste non toccano più il database.

Come si verifica che è risolto

Dopo le modifiche, si ripete il controllo iniziale sotto carico normale:

mysql -u root -p -e "SHOW STATUS LIKE 'Threads_connected'; SHOW STATUS LIKE 'Max_used_connections';"

Max_used_connections indica il picco massimo registrato dall'ultimo riavvio: se resta stabilmente sotto il valore di max_connections anche nei momenti di traffico più alto, il problema è risolto. Se torna a salire, il pool o la cache non stanno intercettando il traffico come previsto, e va rivista la configurazione lato applicazione.

Se il problema è del fornitore

Su hosting condiviso o VPS gestiti, max_connections è spesso impostato dal provider e non modificabile dal cliente. Se l'errore si presenta regolarmente nei picchi di traffico, va aperto un ticket all'assistenza allegando: l'orario esatto dell'errore, l'output di SHOW FULL PROCESSLIST se accessibile, e il traffico medio del sito in quella fascia oraria. È il provider a dover verificare se il piano acquistato prevede un limite di connessioni adeguato al traffico dichiarato.