MySQL Prozesse bleiben bei externem DB-Zugriff in close_wait (bis nichts mehr geht)

[kirladu]

Hallo Leute,
ich hoffe, dass mich jemand bei einem Problem, das mich schon mehrere Wochen begleitet, auf die richtige Fährte bringen kann.

Eine Applikation auf Server A benötigt auf Server B externen Datenbank-Zugriff. Es finden zahlreiche Abfragen statt. Nach mehreren Stunden lahmen beide Server, da die MySQL-Verbindungen nicht mehr geschlossen werden. Zahlreiche mysqld Prozesse bleiben auf Server B offen und in der netstat Liste wird eine lange Liste mit close_wait TCP-Verbindungen angezeigt.
Ergebnis ist, dass nginx auf Server A Fehlermeldungen Error 502 wegen Problemen beim upstream-Zugriff (MySQL-Socket) wirft und Server B nur mehr äußerst träge bis gar nicht auf Datenbank-Abfragen reagiert.

Auf Server A läuft eine PHP-Applikation (auf Zend Framework 1), die eigentlich nach verwendeter Verbindung am Ende aufräumen und die Verbindungen kappen sollte. Da es sich teilweise um länger laufende Cron-Skripts handelt und sich in mehreren Foren Hinweise gefunden haben, dass man in diesem Fall die Verbindung über closeConnection schließen soll, habe ich diesen Aufruf in die relevanten Funktionen integriert. Leider ohne Erfolg.

Möglicherweise wichtige Beobachtung:
Selbst wenn bei Server B in ISPConfig der externe Zugriff auf die DB deaktiviert wurde und bei einem Verbindungsversuch von Server A "Server A ist nicht erlaubt, zuzugreifen" zurückgemeldet wurde, blieb die Problematik mit den close_wait Prozessen und auf Server B wurden bis zur Überlastung zahlreiche mysqld-Prozesse geöffnet, die sich nicht mehr schlossen. Erst durch Schließen des Port 3306 über iptables war Ruhe und ein normaler Betrieb möglich.

Konfiguration Server A:
Debian 3.2.65-1+deb7u1 x86_64
mysql Ver 14.14 Distrib 5.5.41
nginx/1.2.1
ISPConfig 3.0.5.4p5

Konfiguration Server B:
Debian 2.6.32-5-amd64
mysql Ver 14.14 Distrib 5.1.73
Apache/2.2.16
ISPConfig 3.0.5.3

Somit meine dringende Frage: Wie bringe ich die beiden Server dazu, bei externem DB-Zugriff miteinander zu kommunizieren und anschließend die Verbindung auch wieder zuverlässig zu schließen, die mysqld-Prozesse zu beenden und die TCP-Ports freizugeben?

Vielen Dank im Voraus!

 

[nowayback]

was spricht in dem fall gegen eine persistente verbindung?
Klar, löst dein Problem nicht, sondern umgeht es, aber wenn eh soviele Abfragen gemacht werden, warum dann jedes mal ne neue verbindung aufbauen.

 

[kirladu]

Danke für den Vorschlag! Ich habe jetzt mal alle MySQL-Verbindungen zwischen den Servern auf persistent umgestellt.
Momentan sehe ich zwar trotzdem zahlreiche close_wait Einträge über netstat, bisher (letzte 12 Stunden) ist es aber noch zu keiner Überlastung auf einem der beiden Server oder Ausfällen gekommen.

Da ich aber auch mehrfach kritische Beiträge zur Verwendung von persistent gefunden habe, hoffe ich mal, dass ich mir dadurch keine anderen Probleme einkaufe.

Wie du sagst, ist es eigentlich eine Umgehung des ursprünglichen Problems und die Frage bleibt offen, warum die Verbindungen ohne persistent nicht geschlossen wurden.

 

[Till]

Ansonsten kannst Du auch mal versuchen die beiden folgenden variablen in der mysql my.cnf zu setzen:

interactive_timeout
wait_timeout

Die Timeouts sind jeweils in Sekunden anzugeben.

 

[kirladu]

Wow - 28.800 Sekunden = 8 Stunden als Defaults, bis inaktive Verbindungen geschlossen werden, ist ganz schön heftig. Das klärt zwar nicht die Ursache, warum die Verbindungen nicht geschlossen werden, aber zumindest, warum eine eigenständige (Auf-)Lösung der Situation seeehr lange auf sich warten lässt.

http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html#sysvar_wait_timeout
http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html#sysvar_interactive_timeout

Mal probieren, aber das sollte sich locker auf 3.600 oder weniger Sekunden reduzieren lassen.

Danke Till!