Monitoraggio delle perdite di connessione MySQL

Question

Ho un server applicazioni (jetty 6 su una macchina Linux) che ospita 15 applicazioni individuali (singole di guerra). Ogni 3 o 4 giorni ricevo un avviso da nagios per quanto riguarda il numero di connessioni TCP aperte. Dopo l'ispezione, vedo che la stragrande maggioranza di queste connessioni è verso il server MySQL.

netstat -ntu | grep TIME_WAIT 

Spettacoli 10.000 connessioni al server MySQL dal server delle applicazioni (notare lo stato è TIME_WAIT). Se riavvio il molo, le connessioni scendono quasi a zero.

Alcuni valori interessanti da uno stato di spettacolo:

mysql> show status; 
+--------------------------+-----------+ 
| Variable_name   | Value  | 
+--------------------------+-----------+ 
| Aborted_clients   | 244  | 
| Aborted_connects   | 695853860 | 
| Connections    | 697203154 | 
| Max_used_connections  | 77  | 
+--------------------------+-----------+ 

A "spettacolo processlist" non mostra nulla di straordinario (che è quello che ci si aspetterebbe in quanto la maggior parte dei collegamenti sono al minimo - ricorda il TIME_WAIT stato dall'alto).

Ho un env di TEST per questo server ma non ha mai avuto problemi. Ovviamente non riceve molto traffico e il server delle applicazioni viene costantemente riavviato, quindi il debug non è di grande aiuto. Immagino di poter scavare in ogni singola app e scrivere un test di carico che colpisca il codice del database, ma questo richiederebbe molto tempo/problemi.

Qualche idea su come sia possibile rintracciare l'applicazione che sta afferrando tutte queste connessioni e non lascerà mai andare?

Answer 1

La risposta sembra essere l'aggiunta delle seguenti voci nella my.cnf sotto [mysqld] :

wait_timeout=60 
interactive_timeout=60 

ho trovato qui (fino in fondo): http://community.livejournal.com/mysql/82879.html

Il valore di default tempo di attesa per uccidere una connessione stantia è 22800 secondi. per verificare:

EDIT: Ho dimenticato di dire, ho anche aggiunto il seguente al mio /etc/sysctl.conf:

net.ipv4.tcp_fin_timeout = 15 

Questo dovrebbe contribuire a ridurre la soglia di attesa del sistema operativo prima di riutilizzare le risorse di connessione.

EDIT 2: /etc/init.d/mysql ricaricare non sarà davvero ricaricare il my.cnf (vedi link sotto)

Answer 2

Beh, una cosa che mi viene in mente (anche se non sono un esperto su questo) è aumentare il log in mySQL e cercare tutti i messaggi di connessione/chiusura. Se ciò non funziona, puoi scrivere un piccolo proxy per sederti tra l'attuale server mySQL e la tua suite di applicazioni che esegue la registrazione aggiuntiva e saprai chi sta connettendo/uscendo.

Answer 3

Probabilmente i pool di connessioni sono configurati in modo errato per contenere troppe connessioni e si stanno aggrappando a troppi processi inattivi.

A parte questo, tutto ciò a cui riesco a pensare è che un pezzo di codice è trattenuto su un set di risultati, ma sembra meno probabile. Per catturare se si tratta di una query lenta che è scaduta, puoi anche impostare mysql in modo che scriva in un log di query lento nel file conf e poi scriverà tutte le query che richiedono più tempo di X secondi (il valore predefinito è 5, penso) .

Answer 4

SHOW PROCESSLIST mostra all'utente, host e database per ogni thread.A meno che tutte e 15 le tue app non stiano utilizzando la stessa combinazione, dovresti essere in grado di differenziare l'utilizzo di queste informazioni.

Answer 5

Ho avuto lo stesso problema con +30.000 TIME_WAIT sul mio server client. Risolto il problema con l'aggiunta, in /etc/sysctl.conf:

net.ipv4.tcp_syncookies = 1 
net.ipv4.tcp_tw_reuse = 1 
net.ipv4.tcp_tw_recycle = 1 
net.ipv4.tcp_fin_timeout = 30 

Poi:

/sbin/sysctl -p 

dopo 2 o 3 minuti, i collegamenti TIME_WAIT sono passati da 30 000-7 000.

Answer 6

/proc/sys/net/ipv4/tcp_fin_timeout era 60 in RHEL7.tcp_tw_reuse e tcp_tw_recycle è stato modificato in 1 e le prestazioni sono migliorate.