Mit max_clients definiert man bei einem MySQL Server, wie viele Client Connections die Datenbank maximal akzeptiert. Wird diese Anzahl erreicht, können keine weiteren Verbindungen zur Datenbank gemacht werden und MySQL schmeißt uns den Fehler „Too many connections“ zurück.
Bei großen Applikationen wie zum Beispiel Communities oder Shopsystemen kommt es durchaus vor, dass man nicht nur die Webanwendung, vulgo das PHP hat, die auf die Datenbank zugreift. Unter Umständen gibt es noch Backend-Systeme, Batch-Prozesse, Shell-Scripte und ähnliches, die sich ebenfalls zur Datenbank verbinden wollen. In Summa greifen da also ganz schön viele verschiedene System auf die Datenbank zu. Nun muss man noch wissen, dass bei einer typischen Konfiguration aus Apache + PHP pro httpd Prozess in der Regel mindestens eine Datenbank-Verbindung offen ist (es sei denn man versucht sich mit einem Connection Pooling über SQLRelay oder MySQL Proxy). Das schöne an der „shared nothing“ Architektur von PHP ist ja, dass am Ende des Requests die Verbindung zur Datenbank wieder geschlossen wird, also wieder ein Connectionslot frei wird.
Um also zu verhindern, dass es in Spitzenlastzeiten zu der oben erwähnten Fehlermeldung kommt, muss man über alle Architekturbereiche hinweg berechnen, wie viele Verbindungen maximal zur MySQL Datenbank gleichzeitig erreicht werden könnten. Diesen Mindestwert muss man dann als max_connections eintragen. Zu Problemen kann es kommen, wenn man langlebige Prozesse (Batch-Applikationen oder irre gelaufene Prozesse, die wirr im System „stehen“, Rekursionsbugs, die n Verbindungen ungeplant öffnen usw.) hat, die entsprechend viele Verbindungen zur Datenbank „besetzen“, ob nun gewollt oder ungewollt.
Zu Problemen kann es aber auch kommen, wenn man Peaks in den Seitenaufrufen hat. Da ja ein httpd Prozess dann mindestens eine Verbindung zur Datenbank aufmacht, sollte über die Apache Konfigurationsdirektiven, die die Anzahl der maximalen httpd Prozesse festlegen, die Gesamtzahl der Datenbankverbindungsslots konfiguriert und damit geregelt werden.
Kollege Köhntopp ergänzt noch, dass zum Debugging ein „SHOW FULL PROCESSLIST“ + date ein mal pro Minute in ein Logfile eine Möglichkeit wäre, um zu monitoren, ob es Überläufe gibt. Ich meine, dass die Non-Bastelvariante, der MySQL Enterprise Monitor (Codename Merlin) aus der MySQL Enterprise Distribution, ebenfalls geeignete Mechanismen fürs Monitoring und Logging zur Verfügung stellt. Zusätzlich sollte man bedenken, dass ein max_clients auch immer noch mit einem open_files_limit einhergeht, weil jeder offene Socket natürlich auch ein Filehandle belegt. Eine Tabelle belegt 2-3 Filehandles, somit ergibt sich die knackige Formel open_files_limit = (max_clients + table_cache * 2 bis 3).
Schreibe einen Kommentar