Too many connection

[Floezen]

Too many connections

Hallo,

ich habe zwei Fragen zu einem MySQL Problem:

1. Wir betreiben ein vBulletin Forum. Seit kurzem gibt es nach ca. zwei Wochen Betrieb immer eine Datenbankfehlermeldung „von vBulletin“, die besagt: function.mysql-connect: Too many connections.
   Die Seite wir folglich nicht mehr aufgebaut.
   Eine andere Seite auf dem gleichen Server läuft aber problemlos weiter und kann auf MySQL zugreifen. Wird in der MySQL Konfiguration oder woanders irgendwo festgelegt, wer wie viele Verbindungen aufbauen darf???
   
2. Die Anzahl der maximalen Verbindungen in der my.cnf ist per Voreinstellung auf 100 gesetzt. Ich hatte den Wert bereits um 20% erhöht, der o.g. Fehler tritt aber immer noch auf. Kann mir jemand eine grobe Einschätzung geben, auf welchen Wert ich dies für einen reinen Web- und Mailserver mit folgender Hardware sinnvoll erhöhen könnte/sollte:
   - AuthenticAMD, AMD Athlon(tm) 64 X2 Dual Core Processor 4200+
   - 2GB RAM

Danke & Grüße
Flözen

 

[Roger Wilco]

Wird in der MySQL Konfiguration oder woanders irgendwo festgelegt, wer wie viele Verbindungen aufbauen darf???

http://dev.mysql.com/doc/refman/5.5/en/user-resources.html

Kann mir jemand eine grobe Einschätzung geben, auf welchen Wert ich dies für einen reinen Web- und Mailserver mit folgender Hardware sinnvoll erhöhen könnte/sollte:

http://www.rootforum.org/forum/viewtopic.php?f=103&t=36343

 

[Floezen]

http://dev.mysql.com/doc/refman/5.5/en/user-resources.html

Hmm, max_user_connections ist bei mir nicht gesetzt. Daran kann's nicht liegen...
Aber wieso streikt die eine Seite und die anderen laufen weiter???

http://www.rootforum.org/forum/viewtopic.php?f=103&t=36343

Dort wird
max_connections = 24
empfohlen. Ist das nicht etwas wenig? Der Default liegt schon bei 100 und bis zu 1000 sollten maximal unter Linux möglich sein. Wieso werden hier so wenig Verbindungen empfohlen?

Grüsse
Flözen

 

[Huschi]

Aber wieso streikt die eine Seite und die anderen laufen weiter???

Weil es lediglich ein kurzzeitiges Phänomen sein kann.

Ist das nicht etwas wenig?

Hängt von den anderen Speicheraufteilungen ab. Diese Empfehlung sollte man auch immer mit seinem Zeitpunkt der Entstehung betrachten.

Der Default liegt schon bei 100 und bis zu 1000 sollten maximal unter Linux möglich sein.

Der Default kann auch schon mal zu viel sein.
1000 geht unter Linux (im allgemeinen) schon. Aber es ist und bleibt eine Frage des vorhandenen Speichers.

Um es mal einfach zu erklären:
Du hast auf der einen Seite den Apache mit X möglichen Connections. Auf der anderen MySQL mit Y möglichen Verbindungen.
Wenn X deutlich größer als Y kann es zum o.g. Fehler kommen. Denn mehr gleichzeitige Request mehrere gleichzeitige DB-Connections öffnen.
Wenn X gleich oder kleiner als Y ist, besteht diese Gefahr nicht.

Nun noch die Sache mit dem RAM:
X gestartete Request verbrauchen X * apache-Data an RAM. Y DB-Connections entsprechen Y * mysqld-Data. Wenn die Summe daraus größer als der vorhandene Speicher wird, beginnt der Server zu swappen und das System hat eine kritischen Moment erreicht.

Es gilt also die passenden Werte für X und Y zu finden, die erstens ausreichend DB-Connections hält, aber den System-Speicher nicht überlaufen lassen.

Sowohl der Apache- als auch der MySQL-Data-Speicher sind systemspezifische Variablen die mithilfe von anderen Parametern beeinflusst werden können.

Oder kurz gesagt: Eine pauschale Aussage von "max_connections = 24" ist totaler Quatsch!
Jeder Server muss individuell auf seine Einstellung und Aufgaben eingestellt werden.
Dies ist auch nicht mit einem einmaligen Optimierungsvorgang erledigt.
Siehe auch Server-Optimierung

huschi.

 

[d4f]

Was sagt denn tuning-primer?
Schliesst eventuell ein Prozess nicht korrekt seine MySQL-Verbindungen? (Entweder ueber phpMyAdmin oder 'SHOW PROCESSLIST' visualisierbar)

 

[Joe User]

Oder kurz gesagt: Eine pauschale Aussage von "max_connections = 24" ist totaler Quatsch!

Wird dort auch nicht gemacht.

Jeder Server muss individuell auf seine Einstellung und Aufgaben eingestellt werden.
Dies ist auch nicht mit einem einmaligen Optimierungsvorgang erledigt.

Richtig, deshalb steht es dort auch seit fünfeinhalb Jahren so.

 

[Floezen]

Weil es lediglich ein kurzzeitiges Phänomen sein kann.

Dann ist das aber ein ziemlich dauerhaft kurzzeitig einseitiges Phänomen:
Mir ist natürlich klar, dass diese Meldung eigentlich nur für die Dauer des Problems erscheinen sollte, allerdings erklärt sich mir dann nicht, warum die Meldung auf Seite A über mehrere Minuten entsteht, während auf Seite B gleichzeitig alles reibungslos läuft...

Um es mal einfach zu erklären:
Du hast auf der einen Seite den Apache mit X möglichen Connections. Auf der anderen MySQL mit Y möglichen Verbindungen.
Wenn X deutlich größer als Y kann es zum o.g. Fehler kommen. Denn mehr gleichzeitige Request mehrere gleichzeitige DB-Connections öffnen.
Wenn X gleich oder kleiner als Y ist, besteht diese Gefahr nicht.

Ahh, das hört sich doch interessant an.

Meine info.php gibt mir dazu folgende Apache Info:

Max Requests =
Per Child: 10000 - Keep Alive: on - Max Per Connection: 100

Timeouts =
Connection: 300 - Keep-Alive: 15

Virtual Server =
Yes

Sehe ich das richtig, dass max 100 Verbindung mit jeweils 10000 Child Requests zugelassen sind???
Was genau machen den die Child Prozesse?
Würde das bedeuten, dass MySQL also mind. 100 Verbindungen zulassen sollte?

Nun noch die Sache mit dem RAM:
X gestartete Request verbrauchen X * apache-Data an RAM. Y DB-Connections entsprechen Y * mysqld-Data. Wenn die Summe daraus größer als der vorhandene Speicher wird, beginnt der Server zu swappen und das System hat eine kritischen Moment erreicht.

Schon klar. Mit der neuen Plesk Serverüberwachug konnte ich nachvollziehen, dass normalerweise immer noch ausreichend RAM (mind. 500MB von 2000MB) zur Verfügung standen.
Nur beim letzten "Too many connection" Problem, hatte sich der Apache RAM schlagartig verdreifacht. Die Frage ist, warum???

Oder kurz gesagt: Eine pauschale Aussage von "max_connections = 24" ist totaler Quatsch!
Jeder Server muss individuell auf seine Einstellung und Aufgaben eingestellt werden.
Dies ist auch nicht mit einem einmaligen Optimierungsvorgang erledigt.
Siehe auch Server-Optimierung

Das führe ich mir gerne nochmal zu Gemüte. Mit tunig-primer.sh und mysqltuner.pl habe ich versucht MySQL so gut ich es kann zu optimieren.

Ich möchte aber trotzdem nicht glaube, dass man für einen Webserver, der im Grunde immer mehr oder weniger das Gleiche tut, bei bekannter Software-/Hardwareausstattung nicht schonmal sichere Basiswerte nennen kann, die als Ausgangsbasis für Optimierungen genutzt werden können.

Für Photoshop kann ja andersrum auch eine mind. Voraussetzung für die Hardware genannt werden, ohne dass man weiß, was der Anwender letztlich damit macht...

Grüsse
FLözen

 

[Huschi]

warum die Meldung auf Seite A über mehrere Minuten entsteht, während auf Seite B gleichzeitig alles reibungslos läuft...

Schon in die MySQL-Prozessliste geschaut?

Meine info.php gibt mir dazu folgende Apache Info:

Uff! Kannst Du bitte das original auser Apache-Config hinzuziehen? Auch welches MPM wäre gut: Prefork oder Worker?

Nur beim letzten "Too many connection" Problem, hatte sich der Apache RAM schlagartig verdreifacht. Die Frage ist, warum???

Evtl. hast Du einfach eine hohe Anzahl gleichzeitiger Requests.

Ich möchte aber trotzdem nicht glaube, ... nicht schonmal sichere Basiswerte nennen kann

Dann glaub es halt nicht.
Und der Vergleich mit der Mindestvoraussetzung hat mehrere Haken.

huschi.

 

[Floezen]

Schon in die MySQL-Prozessliste geschaut?

Das werde ich dann beim nächsten Vorkommen wohl mal machen.

Uff! Kannst Du bitte das original auser Apache-Config hinzuziehen? Auch welches MPM wäre gut: Prefork oder Worker?

Wenn ich das jetzt mal so genau wüsste.
Die info.php sagt dazu wieder :

Loaded Modules core prefork http_core mod_so mod_actions mod_alias mod_auth_basic mod_authn_file mod_authz_host mod_authz_groupfile mod_authz_default mod_authz_user mod_authn_dbm mod_autoindex mod_cgi mod_dir mod_env mod_expires mod_include mod_log_config mod_mime mod_negotiation mod_setenvif mod_ssl mod_userdir mod_php5 mod_perl mod_python mod_rewrite mod_fcgid mod_headers mod_suexec mod_bw mod_deflate

und

DAEMON /usr/sbin/httpd2-prefork

Also vermutlich prefork dann?!

Dazu sagt /etc/apache2/server-tuning.conf:

<IfModule prefork.c>
        
        StartServers         5
        MinSpareServers      5
        MaxSpareServers     10
        ServerLimit        150
        MaxClients         150
        MaxRequestsPerChild  10000
</IfModule>

# worker MPM
<IfModule worker.c>
        StartServers         3
        MinSpareThreads     25
        MaxSpareThreads     75
        ThreadLimit         64
        MaxClients         150
        ThreadsPerChild     25
        MaxRequestsPerChild  10000
</IfModule>

KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 15
#EnableMMAP off
#EnableSendfile off

Wenn ich das mit dem zuvor gesagten dann richtig verstehe, sollte ich wg. der 150 MaxClients die 150 Verbindungen auch bei MySQL einstellen, bzw. beides reduzieren und mind. genausoviele MySQL Verbindungen wie MaxCLients zulassen?!

Evtl. hast Du einfach eine hohe Anzahl gleichzeitiger Requests.

Was hieße das im Detail? Zu viele Nutzer, die auf die Seiten zugreifen oder Skripte, die mehrere Verbindungen gleichzeitig öffenen?
Ein normales PHP-MySQL Skript arbeitet sich doch von oben nach unten durch. D.h. eine Abfrage nach der anderen wird ausgeführt. Dafür wird auch jedes mal eine neue Verbindung aufgebaut, oder?




Grüsse
Flözen

 

[Fr33z3m4n]

Ein normales PHP-MySQL Skript arbeitet sich doch von oben nach unten durch. D.h. eine Abfrage nach der anderen wird ausgeführt. Dafür wird auch jedes mal eine neue Verbindung aufgebaut, oder?

Im Normalfall NEIN. Aber wer sowas programmiert (was natürlich möglich ist), gehört gesteinigt, geschlagen, in den Keller getrieben usw.

 

[Joe User]

Ein normales PHP-MySQL Skript arbeitet sich doch von oben nach unten durch.

Das ist Richtig und gilt für alle Scriptsprachen, sowie für die meisten Programmiersprachen.

D.h. eine Abfrage nach der anderen wird ausgeführt. Dafür wird auch jedes mal eine neue Verbindung aufgebaut, oder?

Das hängt von den Fähigkeiten des Scriptschreibers ab. Anfänger begehen diesen Fehler gerne, während Fortgeschrittene dies möglichst umgehen.

 

[Huschi]

Wenn ich das mit dem zuvor gesagten dann richtig verstehe, sollte ich wg. der 150 MaxClients die 150 Verbindungen auch bei MySQL einstellen, bzw. beides reduzieren und mind. genausoviele MySQL Verbindungen wie MaxCLients zulassen?!

Das habe ich zwar so grob gesagt. Aber es gibt weitere Feinheiten zu beachten. Z.B. das ja nicht nur PHP-Scripte ausgeführt werden, sondern auch statische Requests: Bilder, JavaScript, CSS, etc.
Das korrekte Verhältnis von Apache-MaxClients und MySQL-Connections kommt halt auch auf die Anwendung an.

Was hieße das im Detail? Zu viele Nutzer, die auf die Seiten zugreifen

Es müssen nicht nur User sein. Es können auch Bots sein.

Aber die Kernfrage ist: Warum kommt die Meldung nur bei der einen Anwendung, während die Anderen weiter laufen?
Die einzige wirklich Erklärung wäre der Link von Roger Wilco über die Einschränkungen der User-Resources. Hast Du Dir wirklich alles darin durchgelesen? Da geht es nicht nur um max_user_connections.

Eine andere Erklärung: Die andere Applikation läuft mit MySQL-root-Rechten.

huschi.

 

[Floezen]

Es müssen nicht nur User sein. Es können auch Bots sein.

Schon klar...

Aber die Kernfrage ist: Warum kommt die Meldung nur bei der einen Anwendung, während die Anderen weiter laufen?
Die einzige wirklich Erklärung wäre der Link von Roger Wilco über die Einschränkungen der User-Resources. Hast Du Dir wirklich alles darin durchgelesen? Da geht es nicht nur um max_user_connections.

Ich steh aufm Schlauch. Um was geht es denn sonst noch? Meinst Du allgemein Ressourcenbeschränkungen?
Also weder in der my.cnf noch in der mysql Tabelle unter "user" gibt es Einschränkungen. Bei ersterem ist gar nichts gesetzt, in der DB steht alles auf "0".
Gibt es noch einen anderen Ort, wo eine Einschränkung vorgenommen werden könnte?

Eine andere Erklärung: Die andere Applikation läuft mit MySQL-root-Rechten.

Definitiv nicht!


Grüsse
Flözen