Archiv verlassen und diese Seite im Standarddesign anzeigen : viel zu hoher Load und Verbindungsprobleme mit der MySQL Datenbank
partyface.de
02.01.07, 17:32
Hi zusammen,
wir betreiben eine Online-Community und haben seit längerer Zeit riesige Probleme mit hoher Load und seit einigen Wochen Probleme mit der Connection zur MySQL DB.
Als Server haben wir den 1&1 Managed Server 3xl64:
AMD Opteron 175 (Dual-Core), 4.096 MB DDR-RAM
Aktuelle Exporte aus der phpmyadmin hab ich auf den Server gelegt:
Status (Laufzeit-Informationen): http://www.partyface.de/infos/status.htm
Servervariablen und -einstellungen: http://www.partyface.de/infos/variable.htm
Beim Load hatten wir eben folgende Werte:
56.08, 58.52, 59.86
Diese Werte erreichen wir aber regelmäßig in den Lastzeiten zwischen 14 und 22 Uhr täglich
262 Prozesse, 254 sleeping, 8 running, 0 zombie, 0 stopped
CPU stats: 85.2 % User, 14.8% System, 0.0% nice, 0.0% idle
Mem: 4149720K total, 3512048K used, 637672K free, 46464 buffers
Swap: 257016K total, 0K used, 257016K free, 2651504K cached
Wir verzweifeln langsam, wer hat Tipps für uns?
Ich hoffe, ihr könnt etwas weiterhelfen. Bis dahin schon mal vielen Dank.
poste auch mal die restliche Ausgabe von top
Ansonsten - was läuft auf dem System? Wieviele PIs / Visits? Evtl. ist die Kiste einfach am Anschlag...
Du schreibst "managed" - was sagen denn die dazu?
partyface.de
02.01.07, 18:25
auf dem Server läuft eine selbstprogrammierte Community, mit etwa 15 Mio. PIs, Visits weiß ich jetzt nicht...
Managed heißt bei 1&1 irgendwie, dass man denen alles vorkauen muss und die es nur umsetzen. Backups usw. machen sie noch selbstsändig.
Wenn ich unsere phpmyadmin auf dem Server aufrufe, erscheint unter Last immer dieser Fehler:
#1203 - User xxx has already more than 'max_user_connections' active connections
Hinzu kommt, dass die Connection zur DB nicht mehr regelmäßig passiert.
Wenn der Server am Ende wäre, würde er ja nur lahm werden, aber irgendwas ist nicht richtig konfiguriert, weil immer die Fehlermeldungen auftreten.
TOP Ausgabe:
19:20:54 up 2 days, 18:20, 1 user, load average: 37.06, 35.57, 42.60
203 processes: 174 sleeping, 29 running, 0 zombie, 0 stopped
CPU states: 47.6% user, 8.2% system, 0.0% nice, 44.2% idle
Mem: 4149720K total, 3629356K used, 520364K free, 56516K buffers
Swap: 257016K total, 0K used, 257016K free, 2884008K cached
PID PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND
29104 16 0 16376 7652 3184 R 6.7 0.0 0:00 php4
29130 16 0 15676 6884 3176 R 5.9 0.0 0:00 php4
29044 15 0 15148 6444 3188 R 4.2 0.0 0:00 php4
29151 16 0 15288 6468 3080 S 4.2 0.0 0:00 php4
29052 16 0 15552 6812 3176 R 3.3 0.0 0:00 php4
29079 16 0 15700 6944 3184 S 3.3 0.0 0:00 php4
29093 15 0 15588 6844 3168 S 3.3 0.0 0:00 php4
22909 16 0 1960 1060 728 S 1.6 0.0 0:00 top
29083 15 0 15708 6980 3184 S 1.6 0.0 0:00 php4
29085 15 0 15700 6936 3184 S 1.6 0.0 0:00 php4
29099 15 0 15704 6972 3200 S 1.6 0.0 0:00 php4
29101 15 0 15700 6948 3200 S 1.6 0.0 0:00 php4
29103 16 0 15580 6852 3184 R 1.6 0.0 0:00 php4
29117 15 0 1936 1036 728 R 1.6 0.0 0:00 top
29157 18 0 13696 3848 2160 R 1.6 0.0 0:00 php4
14148 15 0 4784 2004 1196 S 0.8 0.0 0:00 httpd
27978 15 0 4736 1912 1156 S 0.8 0.0 0:00 httpd
29100 15 0 15480 6744 3172 S 0.8 0.0 0:00 php4
29110 16 0 15496 6756 3160 R 0.8 0.0 0:00 php4
29152 18 0 13320 3472 2160 R 0.8 0.0 0:00 php4
25697 17 2 2732 1528 1024 S N 0.0 0.0 0:00 bash
19696 16 0 4784 2016 1200 S 0.0 0.0 0:00 httpd
31632 15 0 4784 2016 1200 S 0.0 0.0 0:00 httpd
974 16 0 4784 2016 1200 S 0.0 0.0 0:00 httpd
994 16 0 4784 2016 1200 S 0.0 0.0 0:00 httpd
1412 15 0 4784 2072 1256 S 0.0 0.0 0:00 httpd
3316 15 0 4784 2016 1200 S 0.0 0.0 0:00 httpd
3359 15 0 4784 2016 1200 S 0.0 0.0 0:00 httpd
3362 16 0 4784 2032 1212 S 0.0 0.0 0:00 httpd
3400 16 0 4784 2016 1200 S 0.0 0.0 0:00 httpd
3401 15 0 4784 2028 1212 S 0.0 0.0 0:00 httpd
3402 15 0 4784 2072 1252 S 0.0 0.0 0:00 httpd
3403 16 0 4784 2016 1200 S 0.0 0.0 0:00 httpd
3427 15 0 4784 2000 1192 S 0.0 0.0 0:00 httpd
3428 15 0 4784 2016 1200 S 0.0 0.0 0:00 httpd
6001 15 0 4784 2016 1208 S 0.0 0.0 0:00 httpd
6034 15 0 4784 2004 1196 S 0.0 0.0 0:00 httpd
6035 16 0 4784 2016 1200 S 0.0 0.0 0:00 httpd
6304 16 0 4784 2012 1196 S 0.0 0.0 0:00 httpd
6359 15 0 4784 2016 1200 S 0.0 0.0 0:00 httpd
6397 16 0 4784 2012 1196 S 0.0 0.0 0:00 httpd
6398 16 0 4784 2016 1200 S 0.0 0.0 0:00 httpd
6417 16 0 4784 2004 1196 S 0.0 0.0 0:00 httpd
6419 16 0 4784 2016 1208 S 0.0 0.0 0:00 httpd
6420 16 0 4784 2020 1208 S 0.0 0.0 0:00 httpd
6421 16 0 4784 2020 1208 S 0.0 0.0 0:00 httpd
6453 15 0 4784 2016 1200 S 0.0 0.0 0:00 httpd
6454 15 0 4784 2012 1196 S 0.0 0.0 0:00 httpd
6455 16 0 4784 2012 1196 S 0.0 0.0 0:00 httpd
6456 15 0 4784 2016 1200 S 0.0 0.0 0:00 httpd
6457 16 0 4784 2016 1200 S 0.0 0.0 0:00 httpd
6458 15 0 4784 2016 1200 S 0.0 0.0 0:00 httpd
6763 15 0 4784 2016 1200 S 0.0 0.0 0:00 httpd
7921 16 0 4784 2032 1212 S 0.0 0.0 0:00 httpd
7958 16 0 4784 2028 1212 S 0.0 0.0 0:00 httpd
7959 15 0 4784 2072 1256 S 0.0 0.0 0:00 httpd
7983 15 0 4784 2016 1200 S 0.0 0.0 0:00 httpd
7984 15 0 4784 2004 1196 S 0.0 0.0 0:00 httpd
7985 15 0 4784 2004 1196 S 0.0 0.0 0:00 httpd
7986 16 0 4784 2000 1192 R 0.0 0.0 0:00 httpd
8088 16 0 4784 2028 1208 S 0.0 0.0 0:00 httpd
8135 16 0 4784 2016 1200 S 0.0 0.0 0:00 httpd
8136 16 0 4784 2032 1212 S 0.0 0.0 0:00 httpd
29032 16 0 15728 6980 3184 S 0.0 0.0 0:00 php4
29086 18 0 15164 6264 3016 S 0.0 0.0 0:00 php4
29158 16 0 4784 808 0 R 0.0 0.0 0:00 httpd
29159 16 0 12848 1420 1140 R 0.0 0.0 0:00 php4
Scheinbar sucken eure PHP Skripte in Verbindung mit der DB. Jeder PHP4 Prozess zieht bis zu 6% CPU Zeit.
Wieviele gleichzeitige Zugriffe hat eure Seite?
ok....
Man sieht nur http / php-Prozesse. Läuft die DB auf dem gleichen Server?
welche Applikationen und Versionen laufen denn auf dem Ding? Poste auch mal die Konfigs.
Woher kommen die php4-Prozesse? Wie connected sich die App auf die DB? Socket oder per TCP?
Ansonsten: lt. den anderen Seiten, die Du gepostet hast nimmt die DB max. 40 Connections pro User an - Benutzt ihr Pooling / Caches / Castor-ähnliches oder macht jeder Prozess eine eigene Verbindung auf?
partyface.de
02.01.07, 18:43
@bla!zilla:
in Spitzenzeiten sind 700 Leute eingeloggt, also können quasi alle ne Anfrage
an den Server startet
Heißt das also, die Prozesse müssen schneller geschlossen werden, also die Seiten quasi kleiner werden?
Aber der Server dürfte doch dann höchstens lahm werden und nicht andauernd Fehlermeldungen bringen.
Er bringt aber andauernd "Datenbankserver nicht erreichbar"
Der kommt, weil wir die DB folgendermaßen aufrufen:
function connect()
{
mysql_pconnect(xxx)
or die('<h3>Datenbankserver nicht erreichbar</h3>');
mysql_select_db(xx)
or die('<h3>Datenbank nicht vorhanden</h3>');
}
... wie gesagt - steht ja eigentlich auch da:
max_user_connections steht bei euch auf 40 - je nach Userverhalten und Appliktionsdesign (z.B. eine Verbindung pro User pro Session - Session-Timeout auf 30min) ist das nicht viel...
partyface.de
02.01.07, 18:53
@marce:
Man sieht nur http / php-Prozesse. Läuft die DB auf dem gleichen Server?
--> ja, läuft noch auf einem Server, wir wollen aber bald splitten
welche Applikationen und Versionen laufen denn auf dem Ding? Poste auch mal die Konfigs.
--> PHP Version 4.4.4
--> MySQL ist lt. phpmyadmin Version 4.0.25
Woher kommen die php4-Prozesse? Wie connected sich die App auf die DB? Socket oder per TCP?
--> die Verbindung läuft per Socket, also localhost ist der Servername
--> woher die php4 Prozesse kommen, weiß ich nicht, hab es aber meinem Kollegen mal weitergeleitet, vielleicht weiß er es
Ansonsten: lt. den anderen Seiten, die Du gepostet hast nimmt die DB max. 40 Connections pro User an - Benutzt ihr Pooling / Caches / Castor-ähnliches oder macht jeder Prozess eine eigene Verbindung auf?
--> jeder Prozess macht eine eigene Verbindung auf, wobei wir persistente DB Verbindungen nutzen, ansonsten ist mir nichts bekannt...
Ich mag mich jetzt völlig verrennen, aber localhost als Hostname nutzen ist kein Socket. Das ist eine normale IP Verbindung über das Loopback Interface. Klar, den Begriff Socket gibt es auch in der Netzwerkwelt, auch bei TCP/IP. Da wird die Kombination aus IP:Portnummer Socket genannt.
partyface.de
02.01.07, 18:58
@marce:
welcher Wert wäre für die max_user_connections denn geeignet?
@bla!zilla:
kann auch sein, dass ich was falsches im Kopf hab ,-)
AFAIK wird localhost als Socket verbunden, während 127.0.0.1 über TCP geht - jedenfalls habe ich das mal wo gelesen (und Tests haben es damals bestätigt), Quelle müsste ich suchen...
Ansonsten - scheinbar läuft bei euch php als CGI - das ist nicht unbedingt dafür bekannt, ein Renner zu sein, es wird die Modul-Variaten empfohlen. Habt ihr noch irgendwelche "Beschleuniger" installiert oder rein Standard? Oder ist das Absicht?
Desweiteren - ihr habt zwar Query-Caching aktiv, aber scheinbar (wenn ich die Werte richtig im Kopf habe) in recht dezentem Rahmen (16MB) - da ist vermutlich noch einiges an Optimierungspotenzial drin...
Es wäre nun nett, mal die php.ini, apache-Config und die my.cnf zu posten - sonst blubbern wir eher im Nebel rum...
... und nett wäre noch, die Monsterausgabe oben in ein code-Segment zu packen und die reg. Quoting-Funktion von vB zu nutzen - das macht das Lesen ein bisserl übersichtlicher
Irgendwie hab ich das schon vermutet, dass da ne selbstgestrickte Anwendung läuft.
Als erstes würde ich mal versuchen die Vorschläge von PHPMyAdmin mal umzusetzen (Die in rot Hervorgehobenen).
Heißt das also, die Prozesse müssen schneller geschlossen werden, also die Seiten quasi kleiner werden?Nein, dass heisst das eure Skripte und/oder eure Tabellenstruktur und/oder SQL-Abfragen optimiert werden sollten. Das hat erstmal nicht direkt mit der Grösse der Skripte zu tun.
Nachtrag:Einfach mal so, die Applikation von der DB trennen, ohne zu wissen wo das Problem liegt ist eine äusserst schlechte Idee. Es kann x-Fach (in eigenen Tests Faktor 2.5 erreicht) schneller sein, die DB und Applikation auf den gleichen Computer zu belassen (Netzwerklatenz).
partyface.de
02.01.07, 19:28
Ansonsten - scheinbar läuft bei euch php als CGI - das ist nicht unbedingt dafür bekannt, ein Renner zu sein, es wird die Modul-Variaten empfohlen. Habt ihr noch irgendwelche "Beschleuniger" installiert oder rein Standard? Oder ist das Absicht?
Nein, wir haben alles als Standard. Ich kann im Control-Center auswählen:
Einbindung von Perl als Modul oder CGI
Einbindung von PHP als Modul oder CGI
Desweiteren - ihr habt zwar Query-Caching aktiv, aber scheinbar (wenn ich die Werte richtig im Kopf habe) in recht dezentem Rahmen (16MB) - da ist vermutlich noch einiges an Optimierungspotenzial drin...
ok, werde ich weitergeben
Es wäre nun nett, mal die php.ini, apache-Config und die my.cnf zu posten - sonst blubbern wir eher im Nebel rum...
ich versuche mal an die Infos zu kommen, aber weil wir nen managed server haben, haben wir auch keinen direkten Zugriff auf die Dateien...
Kann ich die Informationen evtl. sonstwo auslesen?
Nein, wir haben alles als Standard. Ich kann im Control-Center auswählen:
Einbindung von Perl als Modul oder CGI
Einbindung von PHP als Modul oder CGI
Und was ist ausgewählt?
ich versuche mal an die Infos zu kommen, aber weil wir nen managed server haben, haben wir auch keinen direkten Zugriff auf die Dateien...
Kann ich die Informationen evtl. sonstwo auslesen?Was habt Ihr denn für eine Distribution?
ssh zugriff gibt es, oder? (wüsste sonst nicht woher du die Top-Ausgabe her hast)
partyface.de
02.01.07, 19:32
Irgendwie hab ich das schon vermutet, dass da ne selbstgestrickte Anwendung läuft.
Als erstes würde ich mal versuchen die Vorschläge von PHPMyAdmin mal umzusetzen (Die in rot Hervorgehobenen).
Nein, dass heisst das eure Skripte und/oder eure Tabellenstruktur und/oder SQL-Abfragen optimiert werden sollten. Das hat erstmal nicht direkt mit der Grösse der Skripte zu tun.
ok, gebe ich auch weiter... Wobei wir in letzter Zeit schon einiges optimiert haben und schon eine Besserung eingetreten ist, aber es kommen halt immer wieder neue User hinzu, dass eine Optimierung nicht von langer Dauer ist.
Nachtrag:Einfach mal so, die Applikation von der DB trennen, ohne zu wissen wo das Problem liegt ist eine äusserst schlechte Idee. Es kann x-Fach (in eigenen Tests Faktor 2.5 erreicht) schneller sein, die DB und Applikation auf den gleichen Computer zu belassen (Netzwerklatenz).
hmm... wenn wir die Server trennen, dann über eine direkt Netzwerkverbindung. Aber grundsätzlich gebe ich dir Recht, solange das Problem nicht behoben ist, müssen wir nicht an einer Trennung arbeiten.
partyface.de
02.01.07, 19:35
Und was ist ausgewählt?
hoppla ;-) Einbindung als CGI ist ausgewählt...
Was habt Ihr denn für eine Distribution?
ssh zugriff gibt es, oder? (wüsste sonst nicht woher du die Top-Ausgabe her hast)
SSH Zugriff gibt es...
hoppla ;-) Einbindung als CGI ist ausgewählt...
dann hat phpmyadmin nicht gelogen :-)
SSH Zugriff gibt es...
... und damit solltest Du auch ohne root-Rechnt an die Configfiles kommen - wo die liegen, tja, das hängt nun davon ab, wie 1&1 die Kiste installiert hat...
php.ini liegt lt. phpmyadmin unter /usr/local/lib/ - my.cnf vermutlich unter /etc/
partyface.de
02.01.07, 19:51
dann hat phpmyadmin nicht gelogen :-)
ok ,-) hab es eben umgestellt, da ist der Load auf 2.0 gesunken, aber andauernd konnte keine verbindung zur DB herstellt werden...
... und damit solltest Du auch ohne root-Rechnt an die Configfiles kommen - wo die liegen, tja, das hängt nun davon ab, wie 1&1 die Kiste installiert hat...
php.ini liegt lt. phpmyadmin unter /usr/local/lib/ - my.cnf vermutlich unter /etc/
nee, hab keinen Zugriff auf die Ordner... ich versuche aber mal über 1&1 an die Daten zu kommen...
hm - wenn Du auf die Daten keinen Zugriff hast wird das natürlich eine langwierige Geschichte - dann musst Du wohl für jede Änderung ein Ticket bei 1&1 aufmachen?
... und gerade DB-Optimierung besteht oftmals auf vielem herumprobieren...
partyface.de
02.01.07, 20:01
hm - wenn Du auf die Daten keinen Zugriff hast wird das natürlich eine langwierige Geschichte - dann musst Du wohl für jede Änderung ein Ticket bei 1&1 aufmachen?
... und gerade DB-Optimierung besteht oftmals auf vielem herumprobieren...
jup, mit 1&1 ist derzeit nicht so optimal... aber es gibt doch sicherlich ein paar Parameter, an denen man sofort was machen kann und Besserung eintritt, wie dann wohl die max_user_connections. Soll ich hier mal den Wert 0 eintragen lassen, der laut MySQL Handbuch die Bedeutung „unbeschränkt“ hat?
würde _ich_ nicht machen - unbeschränkt kann ziemlich nach hinten los gehen...
allerdings hatte ich auch noch nie die Situation, dass ich nicht direkt "spielen" konnte und so die Auswirkungen der Änderungen "gleich" gesehen habe.
... ich würde den Wert mal vorsichtig erhöhen (z.B. auf 100) - aber das ist an sich keine optimale Vorgehensweise...
partyface.de
02.01.07, 20:12
... ich würde den Wert mal vorsichtig erhöhen (z.B. auf 100) - aber das ist an sich keine optimale Vorgehensweise...
ok, hab den Wert mal auf 100 setzen lassen, dass dauert aber jetzt ein bisschen...
welche Informationen benötigst du aus der my.cnf, die bekomme ich nämlich nicht zugeschickt, sondern kann nur einzelne Werte erfragen... immerhin etwas...
auf die php.ini kann ich zugreifen, was benötigst du da?
Getreu dem Motto viel hilft viel?
Geh es langsam an, und steiger es wie marce vorgeschlagen hat auf max. 100.
Ich würde mir überlegen mal ein Testsystem aufzustzen, an dem man enige Parameter "testweise" verwändern kann. Klar dort hat man dann keine 15m hits, aber man braucht sich wenigstens keine Sorgen um die Anwender zu machen.
Wie, die Last ist auf 2 gesunken? Das ist doch gut, kamen die Fehler jetzt häufiger?
ähm, tja - schau Dir mal die Doku von MySQL bzw. PHP bezüglich des Konfigfiles an...
-> das komplette File muss da leider sein - oder sollen wir jede einzelne potentielle Variable / Konfigeinstellung abfragen?
partyface.de
02.01.07, 20:18
Geh es langsam an, und steiger es wie marce vorgeschlagen hat auf max. 100.
genau, hab es auf 100 setzen lassen
Ich würde mir überlegen mal ein Testsystem aufzustzen, an dem man enige Parameter "testweise" verwändern kann. Klar dort hat man dann keine 15m hits, aber man braucht sich wenigstens keine Sorgen um die Anwender zu machen.
mal schauen, was sich machen lässt...
Wie, die Last ist auf 2 gesunken? Das ist doch gut, kamen die Fehler jetzt häufiger?
ja, der Load war bei 2, aber die Seite ging nicht mehr ,-) wir haben ja das Problem, dass als Fehler nur "Datenbankserver nicht erreichbar" kommt bzw. ne tolle eigene Fehlermeldung.
Die Datenbank war jedenfalls bei der Umstellung von php als Apache Modul nicht erreichbar...
partyface.de
02.01.07, 20:20
das komplette File muss da leider sein - oder sollen wir jede einzelne potentielle Variable / Konfigeinstellung abfragen?
hier müsste eigentlich alles drin stehen: www.partyface.de/phpinfo.php
partyface.de
03.01.07, 12:33
die max_user_connections haben jetzt den Wert 250
partyface.de
03.01.07, 14:13
es scheint wirklich geholfen zu haben... die Änderung der max_user_connections und die Einbindung von php als Apache-Modul hat den Load auf etwas über 10 gedrückt, quasi um 75 % verringert...
Jetzt haben wir nur noch folgendes Problem. Beim Upload von Fotos erhalten wir die Meldung: Value: 7; Failed to write file to disk.
Wie kann man das beheben?
zur Info die Festplattenkapazität:
10.680,44 MB von 224.406,00 MB verwendet
Noch freier Speicherplatz: 213.725,56 MB
Vieleicht Rechteprobleme? Da das sicherlich wieder eine selbstgestrickte Fehlermeldung ist - fragt den Entwickler...
Was sollen wir da sagen? Hellsehen können wir hier auch nicht...
Ansonsten: Die Load ist aber immer noch zu hoch für meinen Geschmack. Ihr solltet dringend die restlichen Tipps von hier auch durchprüfen...
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.