Ogni connessione costa memoria, che stia lavorando o aspettando. Alzare il limite su un server già al soffitto della memoria trasforma un errore di database in una macchina che va in swap, il che è peggio.

Guardi che cosa è connesso

SHOW PROCESSLIST;
SHOW STATUS LIKE 'Threads_connected';
SHOW VARIABLES LIKE 'max_connections';
  • Molte righe in Sleep - connessioni aperte e mai chiuse. È un problema dell'applicazione, non del database.
  • Molte righe che eseguono la STESSA query - una query lenta, che arriva più in fretta di quanto finisca. Sistemi la query.
  • Righe Locked che durano a lungo - una transazione che tiene un lock mentre tutto il resto si accoda dietro.

Connessioni che non vengono mai chiuse

Uno script che apre una connessione a ogni giro di ciclo, o un pool di connessioni persistenti più grande di quanto il server consenta, esaurirà il limite per quanto in alto lo si metta.

SHOW VARIABLES LIKE 'wait_timeout';
-- default is often 28800: eight hours of holding a sleeping connection

Abbassare wait_timeout a pochi minuti recupera le connessioni abbandonate. È una rete sotto una perdita, non una cura.

Quando alzarlo È la cosa giusta

Se le connessioni stanno tutte facendo lavoro vero e al server avanza memoria, il limite è davvero troppo basso.

SET GLOBAL max_connections = 300;
-- and in my.cnf so it survives a restart
Prima calcoli la memoria per connessione. 300 connessioni da 12 MB l'una fanno 3,6 GB prima che il database abbia messo in cache una sola riga.
Un salto improvviso delle connessioni a un'ora fissa è un cron, non traffico. La processlist durante il picco lo nomina in una riga.