zuviele MySQL-Instanzen werden erzeugt
zuviele MySQL-Instanzen werden erzeugt
am 25.01.2007 15:04:10 von ch_pingel
Hallo,
ich habe unter Linux einen Apachen & MySQL 4.1.
Ich starte nun MySQL und den Apachen. Es werden vom Apachen automatisch
ein paar Scripte gestartet (sagen wir mal 4), die jeder eine
persistente Connection zum MySQL aufbauen. Diese werden auch in der
Prozessliste als Child-Prozesse vom MySQL angezeigt. Allerdings erzeugt
MySQL jetzt (bzw. nach dem Start von MySQL) selber auch noch 8
Child-Prozesse.
Wenn ich jetzt den Apachen mal neu starte, dann werden meine 4
Connections (bzw. MySQL Child-Prozesse) auch ordentlich beendet und neu
gestartet - aber die 8 bleiben erhalten.
Wie kann ich MySQL dazu überreden, daß diese 8 Prozesse nicht
angelegt werden ? - ich brauche diese nicht und ich denke auch (also
eine reine Vermutung durch Beobachtung), daß die mir Probleme für
einen sauberen Server-Betrieb machen.
MFG,
Christoph Pingel
Re: zuviele MySQL-Instanzen werden erzeugt
am 25.01.2007 15:29:02 von Thomas Rachel
ch_pingel@gmx.de wrote:
> Hallo,
>
> ich habe unter Linux einen Apachen & MySQL 4.1.
>
> Ich starte nun MySQL und den Apachen. Es werden vom Apachen automatisch
> ein paar Scripte gestartet (sagen wir mal 4), die jeder eine
> persistente Connection zum MySQL aufbauen.
Warum persistente Connections?
> Wie kann ich MySQL dazu überreden, daà diese 8 Prozesse nicht
> angelegt werden ? - ich brauche diese nicht und ich denke auch (also
> eine reine Vermutung durch Beobachtung), daà die mir Probleme für
> einen sauberen Server-Betrieb machen.
Die persistenten Connections stellen das gröÃere Problem dar.
Thomas
--
Blödsinnige Liedtexte, Teil 1:
"Ich will Dich zu Armbanduhr mich"
"V jnag lbh gb jngpu zr"
Re: zuviele MySQL-Instanzen werden erzeugt
am 25.01.2007 16:34:42 von ch_pingel
Hallo,
> Warum persistente Connections?
Um Ressourcen zu sparen - die Connection muß x tausend Mal am Tag
aufgebaut werden - da laß ich die doch lieber gleich offen.
> Die persistenten Connections stellen das größere Problem dar.
Wieso ? - die habe ich ja unter Kontrolle - aber jene 8 anderen nicht
und die will ich weg haben.
MFG,
Christoph Pingel
Re: zuviele MySQL-Instanzen werden erzeugt
am 25.01.2007 17:37:24 von Axel Schwenke
ch_pingel@gmx.de wrote:
>
> ich habe unter Linux einen Apachen & MySQL 4.1.
>
> Ich starte nun MySQL und den Apachen. Es werden vom Apachen automatisch
> ein paar Scripte gestartet (sagen wir mal 4), die jeder eine
> persistente Connection zum MySQL aufbauen.
Du willst keine persistenten Connections verwenden:
http://groups.google.com/group/comp.databases.mysql/msg/e843 f0b9e59ad710
> Diese werden auch in der
> Prozessliste als Child-Prozesse vom MySQL angezeigt. Allerdings erzeugt
> MySQL jetzt (bzw. nach dem Start von MySQL) selber auch noch 8
> Child-Prozesse.
Das sind keine Prozesse, sondern Threads. Tatsächlich erzeugt MySQL für
jede offene Verbindung einen Thread und zusätzlich noch eine variable
Zahl von Verwaltungsthreads. Variabel deswegen, weil das u.a. von den
konfigurierten Features abhängt.
Wenn nun eine Verbindung geschlossen wird, wirft MySQL den assoziierten
Thread nicht weg, sondern hebt bis zu thread_cache_size dieser Threads
auf, um sie beim nächsten Connect wiederzuverwenden. Apache macht das
übrigens ähnlich, da heißt die Config-Variable MinSpareServers.
> Wie kann ich MySQL dazu überreden, daß diese 8 Prozesse nicht
> angelegt werden ?
Gar nicht.
> - ich brauche diese nicht
Aber MySQL braucht die.
> und ich denke auch (also eine reine Vermutung durch Beobachtung)
Eine *substanzlose* Vermutung. Threads sind billig. ein MySQL-Thread
braucht ca. 200KB RAM, der Rest ist shared. Außerdem *braucht* MySQL
diese Threads (im Gegensatz zu vielen Java-Programmen) *wirklich*.
XL
Re: zuviele MySQL-Instanzen werden erzeugt
am 25.01.2007 17:54:33 von Axel Schwenke
ch_pingel@gmx.de wrote:
>
>> Warum persistente Connections?
>
> Um Ressourcen zu sparen - die Connection muß x tausend Mal am Tag
> aufgebaut werden - da laß ich die doch lieber gleich offen.
Das ist ähnlich sinnvoll wie der Versuch, das Atmen dadurch optimieren
zu wollen, daß man die Luft anhält. "Warum ausatmen? Ich brauch sowieso
den ganzen Tag Luft, da laß ich die lieber gleich drin."
XL
Re: zuviele MySQL-Instanzen werden erzeugt
am 25.01.2007 19:03:03 von ch_pingel
Hallo,
> Du willst keine persistenten Connections verwenden:
Stoß mich mal bitte mit der Nase drauf. (abgesehen davon nutze ich
kein PHP und kein Java - sondern Perl)
Eine weitere Frage, die mich dazu beschäftigt - wieso sollten
persistente Connections so schlecht sein, wenn paar Leute die ich kenne
und die einen sehr viel stärker belasteten Server (MySQL Anfragen
mäßig) haben diese nutzen - und mit persistenten Connections
schnellere Reaktionszeiten mit ihren Foren hinbekommen als ohne. (die
nutzen mysql_pconnect unter PHP)
Sorry, aber was ich noch vorhin als Grund vergessen hatte, weil
verdrängt :)
Und zwar hatte ich zuerst keine persistenten Connections verwendet -
aber da hatte ich das Problem, daß nach einer Weile die
max_connections=3D100 ausgereitzt waren - soviele habe ich aber nie und
nimmer gleichzeitig benötigt ... manche Connections wurden aus
irgendeinem mir unbegreiflichen Grund nicht wieder geschlossen - bzw.
es wurden mehrere Connections aufgemacht (laut mysql-Log standen
manchmal mehrere Connects hintereinander drin), aber nur eine oder so
wurden davon wieder geschlossen.
Ich hatte aber schon x mal meinen Source-Code durchforstet und keine
Fehler ala "kein $sth->finish" aufgerufen oder "kein disconnect
gemacht" gefunden - spätestens bei Beendigung der Scripte rufe ich
einen automatischen Disconnect auf ... na jedenfalls hatte mir das
Probleme bereitet bzw. stand "max_connections erreicht" öfter im
Error-Log drin ... daher bin ich auch auf persistente Connections
umgestiegen, um dem aus dem Weg zu gehen.
> sondern hebt bis zu thread_cache_size dieser Threads
Die ist bei mir 0.
Ich hab mir mal grad show variables angeschaut ... da gibt es ein
"innodb_thread_concurrency" mit dem Wert 8 ... meine Tabellen sind
allerdings MyISAM ... sind die MySQL Tabellen InnoDBs ? (kann mir die
grad nicht anschauen) ... somit könnt ich die Zahl doch eigentlich
runter setzen, wenn dem nicht so ist.
MFG,
Christoph Pingel
Re: zuviele MySQL-Instanzen werden erzeugt
am 25.01.2007 19:59:30 von Thomas Rachel
ch_pingel@gmx.de wrote:
> Hallo,
>
>> Du willst keine persistenten Connections verwenden:
>
> Stoà mich mal bitte mit der Nase drauf. (abgesehen davon nutze ich
> kein PHP und kein Java - sondern Perl)
Spielt keine Rolle. In dem Moment, wo eine Tabelle gelockt ist oder sonst
eine "spezielle Einstellung" gemacht wird, und das Skript bricht - warum
auch immer - ab, wird die Verbindung zurück in den Pool gelegt, um
später evtl. wiederverwendet zu werden. Wann das passiert, ist
unbestimmt; so lange bleibt die Tabelle gelockt. Bedenke, daà der Apache
mit mehreren Prozessen arbeitet. Wenn auch nur einer ein
unkontrolliertes Lock ausführt, haben die anderen das Nachsehen.
> Und zwar hatte ich zuerst keine persistenten Connections verwendet -
> aber da hatte ich das Problem, daà nach einer Weile die
> max_connections=100 ausgereitzt waren - soviele habe ich aber nie und
> nimmer gleichzeitig benötigt ... manche Connections wurden aus
> irgendeinem mir unbegreiflichen Grund nicht wieder geschlossen - bzw.
> es wurden mehrere Connections aufgemacht (laut mysql-Log standen
> manchmal mehrere Connects hintereinander drin), aber nur eine oder so
> wurden davon wieder geschlossen.
Sollte eigentlich umgekehrt sein... Ich weià nicht, wie Perl mit
Datenbankverbindungen umgeht, da solltest Du evtl. eine zuständige
Gruppe fragen (*lang.perl.*)
> Ich hab mir mal grad show variables angeschaut ... da gibt es ein
> "innodb_thread_concurrency" mit dem Wert 8 ... meine Tabellen sind
> allerdings MyISAM ... sind die MySQL Tabellen InnoDBs ? (kann mir die
> grad nicht anschauen) ... somit könnt ich die Zahl doch eigentlich
> runter setzen, wenn dem nicht so ist.
AFAIK sind die mysql-Systemtabellen MyISAM. Könntest Du runtersetzen, ja.
Thomas
--
Wenn nichts an Teflon haftet, wieso haftet dann Teflon an der Pfanne?
Re: zuviele MySQL-Instanzen werden erzeugt
am 25.01.2007 23:25:05 von Axel Schwenke
ch_pingel@gmx.de wrote:
>XL wrote
>> Du willst keine persistenten Connections verwenden:
>
> Stoß mich mal bitte mit der Nase drauf.
Ja, mach ich doch. Hast du eigentlich mal gelesen, worein ich deine
Nase da getunkt habe?
> Eine weitere Frage, die mich dazu beschäftigt - wieso sollten
> persistente Connections so schlecht sein, wenn paar Leute die ich kenne
> und die einen sehr viel stärker belasteten Server (MySQL Anfragen
> mäßig) haben diese nutzen - und mit persistenten Connections
> schnellere Reaktionszeiten mit ihren Foren hinbekommen als ohne. (die
> nutzen mysql_pconnect unter PHP)
Millionen Fliegen ...
Aber ich laß mich gerne überzeugen: zeig mir *harte* Fakten, wo
persistente Connections eine real World Anwendung um wieviel Prozent
schneller gemacht haben. Die einzige "Anwendung" bei der ich von ca.
30% Performanceschub weiß, war ein Benchmark.
In der Praxis ist ein MySQL-Connect so schnell, daß der im Vergleich
schon zu *einer* Query kaum ins Gewicht fällt. Die Probleme durch die
nicht sauber zurückgesetzten Datenbank-Objekte und -Attribute, die
Connection-Scope haben, sind aber real.
> Und zwar hatte ich zuerst keine persistenten Connections verwendet -
> aber da hatte ich das Problem, daß nach einer Weile die
> max_connections=100 ausgereitzt waren - soviele habe ich aber nie und
> nimmer gleichzeitig benötigt ... manche Connections wurden aus
> irgendeinem mir unbegreiflichen Grund nicht wieder geschlossen - bzw.
> es wurden mehrere Connections aufgemacht (laut mysql-Log standen
> manchmal mehrere Connects hintereinander drin), aber nur eine oder so
> wurden davon wieder geschlossen.
Falls das so sein sollte, dann hast du ein Problem. Das wird aber
*nicht* durch die Verwendung persistenter MySQL-Connections gelöst.
Die Praxis zeigt exakt die gegenteilige Wirkung: persistente
Connections führen zu mehr offenen, inaktiven Verbindungen und
fressen so sinnlos Ressourcen.
> Ich hab mir mal grad show variables angeschaut ... da gibt es ein
> "innodb_thread_concurrency" mit dem Wert 8 ... meine Tabellen sind
> allerdings MyISAM ...
Dann solltest du InnoDB ganz abschalten. *Das* würde mal richtig was
bringen. Und du wärst damit auch mal OnTopic.
XL
Re: zuviele MySQL-Instanzen werden erzeugt
am 26.01.2007 12:44:51 von ch_pingel
Hallo,
> Hast du eigentlich mal gelesen, worein ich deine
> Nase da getunkt habe?
Yep.
> Aber ich laß mich gerne überzeugen: zeig mir *harte* Fakten, wo
> persistente Connections eine real World Anwendung um wieviel Prozent
> schneller gemacht haben.
Ob er nun gerade ie Prozente weiß, kann ich nicht sagen - ich frag
ihn, wenn ich ihn wieder treffe.
> Dann solltest du InnoDB ganz abschalten. *Das* würde mal richtig was
> bringen. Und du wärst damit auch mal OnTopic.
Schalte ich die einfach nur ab, in dem ich den Wert auf 0 setze oder
wie nennt sich die Variable ?
MFG,
Christoph Pingel
Re: zuviele MySQL-Instanzen werden erzeugt
am 26.01.2007 12:51:41 von ch_pingel
> wird die Verbindung zurück in den Pool gelegt, um
> später evtl. wiederverwendet zu werden
Jener Pool ... bzw. das Problem, das ich geschildert habe, mit den
offenen DB-Connections ... kann ich eigentlich im MySQL irgendwie
konfigurieren, daß diese nach x Minuten Untätigkeit automatisch
geschlossen und verworfen werden ? ... wenn ich das Problem weiterhin
nicht finde, so daß ich da von der Gegenseite den max_connections
entgegenwirken kann.
MFG,
Christoph Pingel
Re: zuviele MySQL-Instanzen werden erzeugt
am 26.01.2007 16:28:43 von Axel Schwenke
ch_pingel@gmx.de wrote:
>
>> Dann solltest du InnoDB ganz abschalten. *Das* würde mal richtig was
>> bringen. Und du wärst damit auch mal OnTopic.
>
> Schalte ich die einfach nur ab, in dem ich den Wert auf 0 setze oder
> wie nennt sich die Variable ?
skip-innodb
Ansonsten sind die meisten Features, die irgendwie Ressourcen ver-
brauchen per Default entweder abgeschaltet oder nahe am Minimum
konfiguriert.
Die andere Variable, die du suchst, ist wait_timeout.
http://dev.mysql.com/doc/refman/5.0/en/server-system-variabl es.html
XL