"max_connections" überschritten

[Jensemann]

-> 28.800
ich bin von 28-komma-800 ausgegangen ... und oben war 30 ok

-> soll das 28-tausend heissen ???
?????

das wär ja der tausendfache wert??

Da integer keine kommazahlen sind, ja. 28 800 ... MySQL standard eben. Frag mich was die Jungs da so rauchen, muss verdammt gut sein. Lass den mal runtersetzen. Dann hören mit ziemlicher Sicherheit auch deine Probleme auf.

[offroad4fun]

danke

-> das werd ich doch gleich mal weiterleiten ...
-> wenn oben 30 ok ist - und meiner auf 28800 steht -> was ist dann ein guter wert? 100-200 ?? oder gleich runter auf 30?

bezügl. max-connections 100 = ok
-> reicht das wirklich ... auch wenn das forum weiter wächst
-> hab mal ein paar andere forenbetreiber angqutscht, bei denen ist dieser wert meistens zwischen 300 und 500 ???

danke
jedenfalls

lg thomas

[Jensemann]

danke

-> das werd ich doch gleich mal weiterleiten ...
-> wenn oben 30 ok ist - und meiner auf 28800 steht -> was ist dann ein guter wert? 100-200 ?? oder gleich runter auf 30?

Immer erst mit 30 probieren, wenn das Probleme gibt (*) langsam hochschrauben. Wie oben gesagt, 28 800 ist der MySQL-standard, folglichen standen die alle mal da

bezügl. max-connections 100 = ok
-> reicht das wirklich ... auch wenn das forum weiter wächst
-> hab mal ein paar andere forenbetreiber angqutscht, bei denen ist dieser wert meistens zwischen 300 und 500 ???

Für phpBB.de, einen Online Feedreader und diverse andere klein Projekte zusammen verwende ich eine max_connections von 80, also ja. Einige Provider setzen sehr gerne solche immens hohen Werte. Faktisch sind das aber Werte, die die Hardware mit ziemlicher Sicherheit gar nicht verkraften kann. Wir lasten mit ca. 40-60 Connections 1 GB RAM mit der MySQL alleine aus. Wenn die 80 erreicht sind, schwebt die Kiste Loadtechnisch meist im 7. Himmel. Nun sind Forenabfragen auch meist etwas komplexer, so das man eher niedrig ansetzen muss. Wenn du nun einen Counter Service hättest, wo bei jeder Connection, jedem Query, nur ein Integer inkrementiert wird, dann wären mit Sicherheit auch 300 Connections drin.

(*) In aller Regel sind keine Probleme zu erwarten. Einige in Perl geschriebene Daemonen machen mit zu niedrigen Werten aber Stress, da eine alte Version der Perl MySQL Bibliotheken ziemlich verbuggt im Reconnect-Handling ist. Ich glaube aber nicht, das diese Probleme heute noch von Belang sind. Ich habe diese das letzte mal 2005 selbst beobachtet.

[offroad4fun]

DANKE
habs weitergeleitet

Einige Provider setzen sehr gerne solche immens hohen Werte. Faktisch sind das aber Werte, die die Hardware mit ziemlicher Sicherheit gar nicht verkraften kann.

seltsam ... aber ich wills mal glauben hab halt von einigen seiten diese werte gehört - übrigens oben im 3. post liegt die max_connections auch bei 500 ...

lg thomas

[Jensemann]

Im 3. Post war aber die max_user_connections niedriger. Was das ganze auffängt. Bei dir ist die 0=unbegrenzt.

[offroad4fun]

ok - gebe mich geschlagen ...
merke nur wieder, dass ich mich "nüsse" auskenne

DANKE jedenfalls
lg aus wien
thomas

[offroad4fun]

hi!

leider keine guten news:

mein provider hat jetzt die wait_timeout auf 60 gesetzt ...

HAT aber leider NICHTS GEBRACHT



haben nach wie vor die fehlermeldungen ...

(max_connections stehen noch immer auf 100)

danke
lg thomas

[Jensemann]

Naja, vielleicht ist der Server ja auch wirklich ausgelastet. Lass eben mal die max_connections hochsetzen, vielleicht hast du Glück im Unglück, will heissen: Die Seite braucht diese Anzahl an Verbindungen, der Server kann diese aber aushalten.

Eine general-Lösung gibt es nicht. Wenn der Hoster über 100 nicht erhöhen will, setz ihm eine Frist das Problem zu lösen und kündige sonst.

[offroad4fun]

danke

hab jetzt noch von anderer ("ahnunghabender") seite noch folgenden tipp erhalten:

Lass Ihn doch mal selektiv für Deinen webspace, die persistenten Datenbankverbindungen abschalten. Das bedeutet, dass alle Verbindungen nach beendigung der Abfrage wieder gelöscht werden und sich nicht aufaddieren.

keine ahnung was das heisst - aber ich werds mal meinem provider ausrichten

dann geh ich halt noch mal betteln wegen den max_connections ...

ansonsten werd ich wohl wirklich prvider wechseln ... (wieder ein haufen arbeit )

danke
lg thomas

[Jensemann]

Moment, wenn du wirklich persistente Verbindungen nutzt ist die Ursache ja im Grunde klar. Sorry, aber ich bin nicht davon ausgegangen, das jemand sowas ernsthaft machen würde Der Tipp ist also durchaus wertvoll.

Persistente Verbindungen sind SQL-Verbindungen, die nach Abarbeitung des Skriptes nicht geschlossen werden. Wenn eine persistente Verbindung angefordert wird, prüft PHP zuerst, ob bereits eine identische persistente Verbindung (die vielleicht vorher offen geblieben ist) existiert und benutzt sie in diesem Fall. Sollte keine Verbindung existieren, wird eine hergestellt. Eine 'identische' Verbindung ist eine Verbindung, die zu dem gleichen Host mit dem gleichen Usernamen und Passwort hergestellt wurde.

Diese Prüfung scheint in der Praxis aber nur selten zu funktionieren, zumindest wenn man mit PHP arbeitet, es bleiben folglich Verbindungen offen, die nie wieder benutzt werden. Je nach MySQL-Version, in Zusammenhang mit glibc Version und anderen perversionen auf System-Ebene gibt es dann auch Bugs die wait_timeout daran hindern richtig zu funktionieren.

Nun ja, lass mal die pconnects für deinen Server abschalten und dann schau mal.

Du hast doch einen eigenen Server? Oder ist das nur Webspace?