1&1-Server: Hexacore - langsam wie nie und massive DB-Probleme

[soundbear]

Hallo zusammen,

wie stecken momentan voll in der Klemme und ich hoffe hier ein paar Tipps zu bekommen. Wir sind mit einem größeren Webprojekt umgezogen - von einem älteren Dualcore-Rootserver auf einen neuen Hexacore. Liegt alles bei 1&1. Wir hätten uns hier Peformance-Gewinn ausgemalt - momentan läuft aber rein gar nix richtig.

Irgendwie dreht sich das Problem um persistente Mysql-Verbindungen. Die waren erst ausgeschalten, da gabs es Ladezeiten jenseits von gut und böse. Nunmehr ist der neue Server fast genauso wie der alte eingerichtet. Heißt peristente Verbindungen sind erlaubt.

Lasse ich das so fahren ist innerhalb weniger Minuten ein Fehler "Too many connections". Nun haben wir das an allen Ecken und Ende schon begrenzt "max_connections = 100" in der my.conf, in der php.ini ebenfalls auf 100 gesetzt. Irgendwann setzt er wieder aus. Starte eben den mysql-Service neu - dauert Ewigkeiten. Ich check das ganze nicht mehr ...

Wenn ich MySQL und Apache neu starte, dann rennt das Ding unglaublich los und mit jeder Minute und jeder Abfrage wird er langsamer, so als wenn jede Connection alles langsamer macht und den Kanal verstopft. Nach 10 Minuten geht dann gar nix mehr. Wie kann sowas sein? Hatte ich noch nie ...

Hat jemand eine Idee? Ich poste auch gern mal die Configs, falls das hilft.
Das sind aber Großteil keine utopischen Werte - alles normal. Aufm alten Server läufts ja so auch, kapier ich nicht. Nun haben wir auf der neuen Maschine schon alles auf 100 Connections begrenzt (der alte hatte das nicht) und trotzdem gehen 6 Kerne in die Knie ...

[maxi89]

Persistente Verbindungen sind persistente Verbindungen, weil sie eben nicht automatisch wieder geschlossen werden
Dann ist es relativ logisch, dass irgendwann der MySQL-Server dicht macht, weil 100 Verbindungen gleichzeitig offen sind und damit das definierte Limit erreicht ist.

Wie ist denn der Apache eingerichtet?
Den Symptomen nach zu urteilen, dürfte da PHP als FastCGI-Prozess laufen und so 8-12 gleichzeitige Worker aufmachen. Jeder FastCGI-Prozess macht jedoch seine eigene persistente Verbindung auf, womit du mindestens 12 gleichzeitige Verbindungen hast.
Wenn die FastCGI-Prozesse nach 200-300 Requests neugestartet werden und die MySQL-Verbindung dabei nicht geschlossen wird, häufst du halt immer mehr tote Verbindungen an, bis 100 Verbindungen erreicht sind und der MySQL-Server dicht macht.

Wie verbindet ihr denn zum MySQL-Server? Wenn der auf der selben Maschine läuft, bietet sich "localhost" an. Damit verbindet ihr nicht über das langsame TCP sondern durch das lokale Socket und könnt auch auf persistente Verbindungen verzichten.
127.0.0.1 ist zwar auch in gewisser Weise "localhost", aber eben wieder eine TCP-Verbindung - sollte also nur verwendet werden, wenn überhaupt keine Alternative da ist.

[soundbear]

Hallo und danke für die Info.
Das System baut halt auf diesen persistenten Verbindungen auf und eigentlich wollte ich das nicht vorher umprogrammieren.
Anscheinend stellt es aber eine Alternative dar und muss ja irgendwie funktionieren, wenn es das gibt. Schalte ich diesen Modus aus, braucht der Server Stunden, um eine Seite zu bearbeiten.

Wie der Apache genau läuft kann ich nicht sagen (bin da kein Hardcore-Profi). PHP läuft als normales Modul, wie auch hier lokal im über WAMP. Verbunden wird über "localhost" - halt auch die Standardnummer. Kann da aber gern gucken.

Komisch ist eben, dass alles genauso auf dem alten, schwächeren Server gelaufen ist und nun soll's nicht mehr gehen. Glaub ich nicht, das liegt an einer Einstellung im System. Momentan fahren wir auf max_connections = 750 (Empfehlungen sind 500-1000) und es rennt wie ein Bienchen. Allerdings nicht im Belastungstest. Vielleicht waren die 100 auch einfach zu wenig. Allerdings hatten wir auch schon andere Einstellungen mit 500 oder gar unlimitiert und da war die Kiste auch nach kurzer Zeit aus dem Ring ...

Wie gesagt, wir können uns absolut keinen Reim drauf machen.
Unsere Server, auch selbst konfigurierte, liefen immer sehr gut.

[maxi89]

Fehlt euch auf dem neuen Server eventuell das eine oder andere Zusatzmodul? Ich denke da speziell an xCache oder memcached...
Habt ihr wirklich die Konfiguration 1:1 übernommen? Also wirklich _alle_ Konfigurationsdateien mitkopiert?

[MatthiasG]

....Damit verbindet ihr nicht über das langsame TCP sondern durch das lokale Socket und könnt auch auf persistente Verbindungen verzichten.
127.0.0.1 ist zwar auch in gewisser Weise "localhost", aber eben wieder eine TCP-Verbindung - sollte also nur verwendet werden, wenn überhaupt keine Alternative da ist...

[OT] Bist Du dir da sicher, dass diese Aussage stimmt? [/OT]

[soundbear]

Fehlt euch auf dem neuen Server eventuell das eine oder andere Zusatzmodul? Ich denke da speziell an xCache oder memcached...
Habt ihr wirklich die Konfiguration 1:1 übernommen? Also wirklich _alle_ Konfigurationsdateien mitkopiert?

Danke, werde ich gleich mal checken. In puncto Config meinte ich natürlich "nur" Mysql, Apache und PHP. Vielleicht auch nicht 1:1, aber eben was die Eckdaten betrifft, an denen man ja gern mal schraubt. ;-)

Merkwürdigerweise steht der Server auch gerade, obwohl ich alle Services neu gestartet habe und das sämtliche Connections/Threads löscht. Das wundert mich gerade extrem. Es ist keiner auf dem Server, es liegt keine Last an und trotzdem gibts teilweise beim Seitenladen ein Timeout bzw. dauert alles extrem lange. Ich denke, dass das Problem noch irgendwo anders liegt, nur wo. 1&1 rührt sich nicht.

Vielleicht mal eine Frage: Dedicated Server heißt ja nicht unbedingt, dass es dein eigener ist. Steht zwar so bei 1&1, aber weiß da jemand mehr. Kann ja auch ne Shared-Geschichte sein. Da würde mich allerdings gar nix wundern.

[max.m]

Vielleicht mal eine Frage: Dedicated Server heißt ja nicht unbedingt, dass es dein eigener ist.

Doch. Wenn es ein vServer ist sind auf der Hardware mehrere vServer, die aber jeweils ihre mindesten Ressourcen bekommen sollten.
Bei einem Root-Server "gehört" das Blech Dir alleine.

[soundbear]

Ich meine schon das Blech - Server also als Hardware nicht als Service. Die Applikation ist in jedem Fall so performancehungrig, dass wir ja gerade aus dem Grund umgezogen sind. Der Rootserver war ja auch nur für uns. So ein Virtual- oder Shared-Quatsch ist definitiv nicht das Ziel gewesen.

Habe noch mal geguckt, da steht, dass die Kiste dir gehört. VServer gibts nämlich extra:
http://www.1und1.info/xml/order/Serv...&ordernow=true

Das is er und kackt alle 10 Minuten ab, obwohl nichts und niemand drauf ist.

[maxi89]

[OT] Bist Du dir da sicher, dass diese Aussage stimmt? [/OT]

Bin mir ziemlich sicher
Bei einer TCP-Verbindung musst du erstmal über den IP-Stack des Betriebssystems eine Verbindung herstellen (also SYN, SYN-ACK etc...) und dann kommt noch eine Schicht darüber die Aushandlung der MySQL-Protokollversion, Authentifizierung etc...
Beim Socket entfällt zumindest der Teil mit dem TCP-Verbindungsaufbau - das sind zwar nur Millisekunden, aber hier macht es die Masse. Zusätzlich können Bremsen durch langsame Hostnameauflösung und Firewalls hinzukommen, die beim Socket ebenfalls entfallen.

Zum Problem:
Damit meinte ich auch die Konfiguration für die einzelnen Dienste
Es kann leicht passieren, dass man Dateien, die in irgendeinem tief versteckten Unterordner lauern übersieht.
Vergleicht auch mal (wenn der alte Server noch im Zugriff ist) die Ausgaben von phpinfo().
Vielleicht sind da noch irgendwelche Einstellungen, die das vielleicht bremsen könnten.
Insbesondere die Einstellungen unter dem Punkt "mysql" und "mysqli" könnten da interessant sein.

Für MySQL empfehle ich da das "MySQL tuning primer script": http://www.day32.com/MySQL/
Das ist ein hauptsächlich von MySQL-Entwicklern zusammengebasteltes Shell-Script, welches den MySQL-Server analysiert und Tipps gibt, was man verbessern kann.
Dieses Script solltest du laufen lassen, wenn es mal wieder soweit ist und der Server praktisch dicht ist.
Stoppe dann zuerst den Apache und lasse MySQL laufen - die Verbindungen sollten dann ohnehin abgebrochen werden.
Wenn du auch über die lokale MySQL-Konsole nicht mehr auf den Server kommst (was das Script versucht), starte MySQL neu und verbinde dich danach direkt mit einem MySQL-Benutzer, der volle Rechte hat, über die lokale Konsole auf diesen Server.
Wenn der MySQL dicht ist, kannst du mit SHOW PROCESSLIST; eine Liste aller aktiven Verbindungen/Prozesse ausgeben lassen.
Eine "schlafende" Verbindung (da steht auch "sleep" in der Tabelle) kannst du mit KILL ProzessID; abbrechen. "ProzessID" muss natürlich durch die ID ersetzt werden, die in der Prozessliste angegeben ist
Damit hättest du zumindest wieder eine Verbindung frei, um das Primer-Script laufen zu lassen.

[buegelbeatz]

Hallo,

kam bei diesem Problem eigentlich was raus?

Wir sind auch letzen Monat auf eine HexaCore-Maschine gewechselt in der Hoffnung, dass alles schneller l�uft, aber Pustekuchen. Das Thema Persistenz der MySQL-Verbindung ist bei uns ebenfalls aufgetreten, �rgerlich, aber gut, man kann ja irgendwie nicht alles haben (zumindest nicht bei 1und1).

Wesentlich entscheidender jedoch ist das Ph�nomen, das die Dateizugriffe, aus welchen Gr�nden auch immer, qu�lend die Performance nach unten dr�cken. Wir nutzen zwar relativ extensiv Festplatten-Caching-Mechanismen, die jedoch zur Entlastung teilweise auf Ramdisk-Basis laufen und auf den teilweise 4 Jahre alten Maschinen anstandslos ihren Dienst verrichten.
Irgendwie hatte ich den LVM und die neuen Aufrufe f�r die Ramdisk-Generierung in Verdacht, jedoch haben wir auch den RAID mit tw_cli �berpr�ft und in den Log-Dateien findet sich auch nichts verd�chtiges.

Ein zus�tzlicher Effekt ist, dass HTTP-Seitenaufrufe in der Entwicklungsumgebung (wenig Cache - viele Dateizugriffe) mitten im Request abbrechen (Puff!) ohne Spuren im Apache-Log oder sonstwo zu hinterlassen, ein Software-Update �ber Yast wurde auch schon absolviert. Da liegen die m�glichen Fehlerquellen ja sowohl in der Apache-Konfiguration und -Version, als bei PHP und/oder MySQL. Unser PHP-Framework wurde 1:1 von den alten Maschinen �bernommen, lediglich das Peristenz-Attribut musste angepasst werden.

Eine Nachfrage bei 1und1 f�hrt lediglich zur Aussage ' von hier l�uft alles super!', was einem dann auch nicht wirklich weiterhilft.

Hier noch die Festplattenaufteilung:

Filesystem 1K-blocks Used Available Use% Mounted on
rootfs 11543016 377616 11165400 4% /
devtmpfs 16461500 124 16461376 1% /dev
tmpfs 16498164 4 16498160 1% /dev/shm
/dev/sda1 11543016 377616 11165400 4% /
/dev/mapper/vg00-usr 4184064 2444736 1739328 59% /usr
/dev/mapper/vg00-var 4184064 302740 3881324 8% /var
/dev/mapper/vg00-home
1077925888 208992 1077716896 1% /home
/dev/mapper/vg00-srv 1077925888 88361120 989564768 9% /srv
none 65536 34612 30924 53% /srv/www/htdocs/system/live
none 65536 37800 27736 58% /srv/www/cache/ram
none 1048576 4132 1044444 1% /home/www/logs

Ein TOP-Mitschnitt:

top - 15:10:58 up 8:49, 1 user, load average: 2.02, 1.37, 1.93
Tasks: 290 total, 2 running, 287 sleeping, 0 stopped, 1 zombie
Cpu(s): 5.0%us, 1.5%sy, 0.0%ni, 92.6%id, 0.7%wa, 0.0%hi, 0.2%si, 0.0%st
Mem: 32222M total, 7313M used, 24908M free, 4M buffers
Swap: 49983M total, 0M used, 49983M free, 4221M cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
12905 wwwrun 20 0 386m 20m 4856 S 37 0.1 0:01.50 httpd2-prefork
27440 wwwrun 20 0 385m 18m 4416 S 14 0.1 0:03.72 httpd2-prefork
12913 wwwrun 20 0 383m 17m 4320 S 12 0.1 0:00.37 httpd2-prefork
12938 wwwrun 20 0 385m 18m 4336 S 5 0.1 0:01.01 httpd2-prefork
12921 wwwrun 20 0 384m 17m 4976 S 4 0.1 0:00.60 httpd2-prefork
12889 wwwrun 20 0 389m 23m 4992 S 2 0.1 0:01.03 httpd2-prefork
12906 wwwrun 20 0 383m 16m 4844 S 2 0.1 0:00.09 httpd2-prefork
12903 wwwrun 20 0 383m 15m 3612 S 1 0.0 0:00.03 httpd2-prefork
12912 wwwrun 20 0 382m 15m 4192 S 1 0.0 0:00.03 httpd2-prefork
12952 wwwrun 20 0 383m 16m 4788 S 1 0.1 0:00.10 httpd2-prefork
27442 wwwrun 20 0 382m 15m 4300 S 1 0.0 0:00.10 httpd2-prefork
1567 wwwrun 20 0 385m 19m 4904 S 1 0.1 0:00.79 httpd2-prefork
12883 wwwrun 20 0 386m 19m 4412 S 1 0.1 0:00.94 httpd2-prefork
12885 wwwrun 20 0 384m 17m 4356 S 1 0.1 0:00.11 httpd2-prefork
12901 wwwrun 20 0 383m 15m 3608 S 1 0.0 0:00.02 httpd2-prefork
12931 wwwrun 20 0 385m 18m 4336 S 1 0.1 0:00.10 httpd2-prefork
95 root 20 0 0 0 0 S 0 0.0 0:12.07 kworker/4:1
3028 mysql 20 0 10.5g 2.2g 5564 S 0 6.9 3:07.90 mysqld
3051 root 20 0 0 0 0 S 0 0.0 0:15.84 flush-253:3
12882 wwwrun 20 0 382m 15m 3612 S 0 0.0 0:00.06 httpd2-prefork
12886 wwwrun 20 0 383m 15m 3604 S 0 0.0 0:00.03 httpd2-prefork
12891 wwwrun 20 0 382m 15m 3612 S 0 0.0 0:00.02 httpd2-prefork
12898 wwwrun 20 0 382m 15m 4068 S 0 0.0 0:00.02 httpd2-prefork
12902 wwwrun 20 0 382m 12m 1468 S 0 0.0 0:00.01 httpd2-prefork

Ein Aufruf der der die Kiste sch�n in die Knie zwingt:

nice -n 19 find $cachePath/proxy -ctime +30 -type f -delete

In dem entsprechenden Ordner sind zwar einige Millionen Dateien, lief vorher aber auch ohne Probleme. Ein Umbau in eine Schleife mit rm auf die einzelnen Dateien hat auch keine Besserung gebracht (Man beachte auch den vorsoglich schon entsprechend gew�hlten nice-Wert).

Apache-Performance-Conf:

<IfModule prefork.c>
# number of server processes to start
# http://httpd.apache.org/docs/2.2/mod...l#startservers
StartServers 10
# minimum number of server processes which are kept spare
# http://httpd.apache.org/docs/2.2/mod...inspareservers
MinSpareServers 10
# maximum number of server processes which are kept spare
# http://httpd.apache.org/docs/2.2/mod...axspareservers
MaxSpareServers 15
# highest possible MaxClients setting for the lifetime of the Apache process.
# http://httpd.apache.org/docs/2.2/mod...ml#serverlimit
ServerLimit 250
# maximum number of server processes allowed to start
# http://httpd.apache.org/docs/2.2/mod...tml#maxclients
MaxClients 250
# maximum number of requests a server process serves
# http://httpd.apache.org/docs/2.2/mod...questsperchild
MaxRequestsPerChild 10000
</IfModule>

Nachdem ich auch s�mtliche Konfigurations-Einstellungen auf evtl. Abweichungen von den alten Werten verifiziert habe, bin ich langsam mit meinem Latein am Ende.