RootForum Community

Hallo,
da unser Server den Ansturm an unsere Seite nicht mehr standgehalten hat, haben wir jetzt ein 2. auf dem die Datenbank läuft. Das ganze lief auch ganz gut, aber in den letzten Tagen häuft sich der Fall, dass einzelne Aufrufe oder zu manchen Zeiten auch jeder einzelne extrem lang braucht 30-120s. Auf den Server läuft ein Online Spiel mit relativ aufwendigen php code. Das verwunderliche ist aber, dass in so Zeiten der load auf beiden Servern nicht sonderlich hoch ist. Es ist viel mehr so, dass der MySQL Server extrem lange braucht zum Antworten. Was mir aufgefallen ist, dass im SHOW PROCESSLIST extrem viele Sleep querys vorhanden sind.

Auf PHP Seite benutzte ich PEAR DB ohne persistente Connections

Beide Server laufen auf Debian Etch mit Standard Paketen.

Weiß jemand woran das liegt oder in welche Richtung ich da Suchen muss?

Was mir noch aufgfallen ist:
Wenn ich den gleichen query auf dem MySQL und auf dem Webserver ausführe dauert er auf dem MySQL immer 0s und auf dem Webserver 1-20s oder noch länger...

Die querys hängen alle mit der Nachricht "writing to net"

Abgesehen davon dass Debian nicht als Grundlage für schnelle MySQL-Server geeignet ist: Wie sind die beiden Server miteinander verbunden? Von wievielen gleichzeitigen Connections zum MySQLd sprechen wir? Wie sieht die my.cnf aus? Welche Engine?

Das Problem scheint mir irgendwo am Netzwerk zu liegen
Wenn ich von mysql server zum webserver daten mittels scp kopiere bleibt der vorgang nach 192KB mit stalled stehen.
Andersrum funktioniert es aber einwandfrei.

errors bei ifconfig alles 0

Es gibt auf beiden Rechnern kein IP Tables eintrag.

Ich glaub das Problem liegt daran, dass der webserer in einem linux vserver läuft. Zum host server kann ich ohne Probleme senden.

Tesla2k wrote:Es gibt auf beiden Rechnern kein IP Tables eintrag.

Ich glaub das Problem liegt daran, dass der webserer in einem linux vserver läuft. Zum host server kann ich ohne Probleme senden.

Evtl. beschränkungen beim send/rec.
Poste mal die /proc/user_beancounters (falls vorhanden)

Irgendwas beißt sich da ganz gehörig. So viel Leistungsbedarf, dass man einen dedizierten DB-Server braucht - aber für die Applikation soll ein VServer reichen? Ich würde ja fast drauf wetten, dass das ganze besser liefe, wenn der Applikationsserver mit auf den DB-Server migriert wird und die Anbindung über Unix-Sockets läuft.

Mal abgesehen davon: Bei einem VServer dürfte es schwierig werden, das tatsächliche Problem zu diagnostizieren. Wenn es keine Ressourcenbeschränkungen seitens des Providers sind, kommt so ziemlich alles mögliche in Frage - z. B. ein krankes NIC (kaputtes autonegociate), oder auch einfach nur ein VServer-Nachbar, der mit Video-Streaming o. ä. das NIC dichtballert. Vielleicht hängen aber auch zu viele Mutterschiffe am Switch, und der Uplink ist zu schmal... Probleme mit SCP können auch auftreten, wenn zu wenig CPU-Power und/oder zu wenig Entropie zur Verfügung steht. Hast Du es mal mit einem unverschlüsselten Protokoll (HTTP, FTP) versucht?

Wenn Du versuchen möchtest, eventuelle Netzwerkprobleme einzukreisen, mach Dir erst mal ein Ping-Protokoll (jeweils vom und zum Server) und suche besonders nach Ausreißern in der Latenz. Außerdem solltest Du mehrmals traceroute zwischen beiden Rechnern laufen lassen (von beiden Seiten aus) und auch hier auf Knoten mit hoher Latenz achten. Die Latenz ist zwar nicht alles, kann aber auf einen Knoten mit Auslastungs- oder ggf. sogar technischen Problemen hinweisen.

Joe User wrote:Abgesehen davon dass Debian nicht als Grundlage für schnelle MySQL-Server geeignet ist

Ohne jetzt Debian verteidigen zu wollen - aber mindestens 90% der Gesamtperformance kommt bei vergleichbarer Hardware aus der Konfiguration und nicht aus der Distribution (Kompiler-Flags, Kernel-Release etc.). Und die kann man auch unter Debian ordentlich tunen (mal abgesehen davon, dass Debian einen interessanten Ansatz verfolgt, das Logging über den syslogd erledigen zu lassen, so dass der MySQL-Serverprozess um diese Aufgabe entlastet wird).
Aber stimmt schon, unter FreeBSD skaliert MySQL besser als unter Linux *SCNR* 8)

jfreund wrote:

Joe User wrote:Abgesehen davon dass Debian nicht als Grundlage für schnelle MySQL-Server geeignet ist

Ohne jetzt Debian verteidigen zu wollen - aber mindestens 90% der Gesamtperformance kommt bei vergleichbarer Hardware aus der Konfiguration und nicht aus der Distribution (Kompiler-Flags, Kernel-Release etc.).

http://dev.mysql.com/doc/refman/5.0/en/ ... tions.html

jfreund wrote:Aber stimmt schon, unter FreeBSD skaliert MySQL besser als unter Linux *SCNR* 8)

;)

Tesla2k wrote:Was mir noch aufgfallen ist:
Wenn ich den gleichen query auf dem MySQL und auf dem Webserver ausführe dauert er auf dem MySQL immer 0s und auf dem Webserver 1-20s oder noch länger...

Die querys hängen alle mit der Nachricht "writing to net"

Ein "Sleep" heißt nur, daß da eine Verbindung idle ist. Dein Webserver macht ein mysql_pconnect(). Das ist in den meisten Fällen eine Scheißidee. Stell es in der php.ini ab.

Ein "Writing to net" heißt, daß die Query gerade ausgeführt wird (SQL Loop Join läuft). Entweder habt ihr keinen key_cache bzw. innodb_buffer_pool konfiguriert oder Eure Indices sind Mist. Was sagt denn ein EXPLAIN auf solche "Writing to net" Queries?