Aufspüren von MySQL-Verbindungslecks

Question

Ich habe einen Anwendungsserver (Jetty 6 auf einem Linux-Rechner), auf dem 15 einzelne Anwendungen (einzelne War's) laufen. Alle 3 oder 4 Tage erhalte ich von Nagios eine Meldung über die Anzahl der offenen TCP-Verbindungen. Bei der Überprüfung stelle ich fest, dass die überwiegende Mehrheit dieser Verbindungen zum MySQL-Server geht.

netstat -ntu | grep TIME_WAIT

Zeigt mehr als 10.000 Verbindungen auf dem MySQL-Server vom Anwendungsserver aus an (der Status ist TIME_WAIT). Wenn ich Jetty neu starte, sinken die Verbindungen auf fast Null.

Einige interessante Werte aus einem Show-Status:

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

Ein "show processlist" zeigt nichts Ungewöhnliches an (was ich auch erwarten würde, da die meisten Verbindungen im Leerlauf sind - denken Sie an den TIME_WAIT-Status von oben).

Ich habe eine TEST-Umgebung für diesen Server, aber es gibt nie irgendwelche Probleme. Es bekommt offensichtlich nicht viel Verkehr und der Anwendungsserver wird ständig neu gestartet, so dass die Fehlersuche dort nicht viel Hilfe ist. Ich schätze, ich könnte in jeder einzelnen Anwendung graben und einen Lasttest schreiben, der den Datenbankcode treffen würde, aber dies würde eine Menge Zeit / Ärger nehmen.

Haben Sie eine Idee, wie ich die Anwendung ausfindig machen kann, die all diese Verbindungen aufnimmt und nicht mehr loslässt?

Answer 1

/proc/sys/net/ipv4/tcp_fin_timeout war in RHEL7 60. tcp_tw_reuse und tcp_tw_recycle wurden auf 1 geändert und die Leistung verbessert.