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

Dieses Thema im Forum "Installation und Konfiguration" wurde erstellt von kirladu, 2. Feb. 2015.

  1. kirladu

    kirladu New Member

    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!
     
  2. nowayback

    nowayback Well-Known Member

    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.
     
  3. kirladu

    kirladu New Member

    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.
     
    Zuletzt bearbeitet: 3. Feb. 2015
  4. Till

    Till Administrator

    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.
     
  5. kirladu

    kirladu New Member

    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!
     

Diese Seite empfehlen