phpbar.de logo

Mailinglisten-Archive

[php] =?iso-8859-1?Q?AW=3A_=5Bphp=5D_MySQL_f=E4hrt_mit__connect_an_d?= =?iso-8859-1?Q?ie_Wand?= =?iso-8859-1?Q?ie_Wand?=

[php] =?iso-8859-1?Q?AW=3A_=5Bphp=5D_MySQL_f=E4hrt_mit__connect_an_d?= =?iso-8859-1?Q?ie_Wand?= =?iso-8859-1?Q?ie_Wand?=

Sandor Sandor_(at)_mail.handy.de
Mon, 19 Jun 2000 16:31:18 +0200


Hallo, vielen Dank für Eure Unterstützung!

Der Fehler lag primär in der Datenbank. Wir hatten dort zwei kaputte Tabelle
drin. Allerdings ist die Frage, wie es dazu gekommen ist.

Wir haben hier zur Zeit ca. 2000000 Abfragen pro Tag auf die DB. Zu
Stoßzeiten kommen extrem viele Anfragen, die der MySQL anscheinend nicht
bewältigen kann. Die Anzahl der Threats steigt, bis er eigentlich nur noch
Long Querys (>10sek) erzeugt. Dann ist irgendwann auch schluß mit dieser
Meldung (per mysqladmin):

>>mysqladmin: connect to server at 'localhost' failed
>>error: 'Lost connection to MySQL server during query'

Wenn man in dieser Situation den MySQL beendet, werden damit alle aktuellen
Threats sofort gekillt und können damit Fehler in der DB-Struktur
zurückbleiben, wenn gerade Schreibzugriffe auf eine Tabelle stattgefunden
haben? Das scheint mir jedenfalls die Ursache für die aufgetretenen Effekte.
Daraus ergibt sich die Frage, wie man den MySQL so beenden kann, daß dabei
die laufenden Querys ohne Schaden an der DB beendet werden.

Es kommt immer das rcmysql von SuSE zum Einsatz, um die DB zu reloaden. (C)
ist von 1995-1999. Ist da vielleicht ein Fehler drin?




Und ein paar Fragen ergeben sich aus den früher genannten neu:

> Schicht im Schacht ist, wenn die Anzahl der Threads auf 478 gestiegen ist.
Dann werden keine neuen Threads mehr erzeugt und mysql ist stabil tot. Die
Anzahl der max_connections sind auf 5000 (siehe unten).
> - Ist das überhaupt eine sinnvolle Einstellung?

5000 ist sehr viel. Schau mal ob Du so viel wirklich benötigst.

----> Bis wieviel kann MySQL denn ertragen? <----


So isses. Beim Hochsetzen die httpd.conf vom Apache nicht vergessen
sonst gehts in die Hose wie damals bei www.php.net.

----> Was muß man da wie hochsetzen? Was war bei www.php.net damals die
Ursache? <----


> Zur Zeit werden die Verbindungen über mysql_connect hergestellt.
> - Wird es etwas bringen, auf mysql_pconnect umzusteigen?

http://www.koehntopp.de/php/faq-13.html#ss13.9 , bei einem Modul ja.

> - Falls ja, behebt man damit die Ursache oder nur das Symptom?

Ulf:Ausprobieren.
 
Egon:Bei vielen connections eher nein. Ich würde eher in die Kiste mehr RAM
     reinstecken, einzelne Applikation auf andere Server verteilen oder eine
     Cache Proxy im Accelerator Mode vorschalten.

----> Die Kiste ist mit 512MB ausgestattet.

Peter:Was macht Ihr denn damit? Schliesst Ihr Eure Connections wieder? 
      Langsam läuft MySQL eigentlich nie.

----> Werden die Connections zum DB-Server eigentlich wieder gekillt, wenn
das Script abgebrochen wird, oder bleibt die dann bestehen??? Bei _pconnect
wird ja nur ein Kanal erstellt, wenn ich das richtig verstanden habe. Heißt
das eigentlich, daß die Abfragen nur der Reihe nach von der DB beantwortet
werden können, also daß z.B. erstmal ein Ergebnis ausgegeben wird, bevor die
nächste Anfrage entgegengenommen wird? Das wäre ja DAS Todesurteil für
_pconnect. <----


> weitere mögliche Fehlerursachen (?):
> - mysql-Installation (alte Version)

Eine neue Version kann nicht schaden, 3.22.27 ist ja nun auch nicht mehr
brandaktuell... Oh es tatsächlich ein MySQL Problem ist kann Dir die
MySQL Liste sagen.

----> Wo finde ich denn die MySQL-Liste? Es gab doch mal mysql-de, aber ich
finde sie nicht wieder. <----


Tausend Dank,
Sandor


php::bar PHP Wiki   -   Listenarchive