Server immernoch zu lahm

Hallo Forum,

ich habe ja schon seit ewigkeiten Probleme mit der Geschwindigkeit meiner Seite. Jetzt wollte ich mir eure Meinung mal anhören.

Ich habe den V-Server Linux Level 3 bei Strato.
2xCPU
Max RAM 6GB
RAM garantiert 4GB
Debian Squeeze
Nutze APC mit zugewiesenen 64MB

Nun habe ich ja schon seit Ewig Performance Probleme mit meinem Script auf www.youbeats.net den ich damals von agriya.com gekauft habe. Wenn ich mit top meinen Server betrachte fällt auf, dass ich ein Problem mit dem MySQL Server habe.
Ich überwache meinen Server auch mit pingdom.com. Dadurch weiss ich immer wann mein Server nicht mehr ereichbar ist. Da konnte ich schon öfter beobachten, dass dann mehrere Tasks CPU beansprucht haben und diese waren dann immer sql. 5-7 Prozesse, womit ich dann auf 500-700% CPU??!! Auslastung bin, laut top und plesk. Die durschnittliche Seiten Ladezeit laut pngdom.com stand immer bei 1900ms. Gegen Ende des Oktober wurde es immer mehr, dann habe ich am 04.11. mit tuning-primer.sh die Datenbank optimiert. Da war mal einiges zu ändern. Mein Table Cache und table cache definition waren viel zu gering. Also habe ich beide auf 4096 erhöht, nachdem ich gegoogelt und recherchiert habe. Die erhoffte Schnelligkeit blieb aber aus. Die Response Zeit geht garnicht mehr runter. Siehe Screenshot.

Dann habe ich mal nach slow-queries gesucht. Habe mal 4s eingestellt, da ich ja mittlerweile bei einer durchscnitts response Zeit von 11,4s bin. Da gab es aber nur einen Eintrag und zwar wenn die Beats in der letzten Instanz aufgerufen werden z.B. hier:
http://www.youbeats.net/music/listenmusic/4327/diamonds.html

Ich habe mal 3-4 Seiten hintereinander aufgerufen und Screenshot von top bzw. htop gemacht. Macht euch selbst ein Bild. Ich bekomme das nicht in den Griff und weiss auch nicht mehr weiter. Ich habe ca.100-150 Besucher und 1000 Seitenaufrufe am Tag. Managed Server würde sich derzeit nicht lohnen.
Ich erhoffe mir einfach wenn die Seite flott ist, dass sie dann auch mal viel mehr Besucher anziehen wird. Wenn ich ja schon keine Lust hab auf meiner Seite zu surfen wegen der immensen Geschwindigkeit :( dann kann ich das ja auch nicht von anderen verlangen.

Hab ich ein Script, Anbieter oder Server Problem? Ich habe bereits bei Strato gekündigt zu April. Wollte eigentlich zu Server4You wegen der Explosion :( usw. aber jetzt habe ich auch schon wieder soviele Kundenmeinungen gelesen, dass ich mir da auch schon wieder unsicher bin.

Daher bitte ich um Hilfe.

Nächster Schritt wäre....alles löschen und Sorgenfrei sein. Das möchte ich aber nicht, da ich einfach schon zuviel in die Seite investiert habe.
 

Attachments

  • pingdom.png
    pingdom.png
    56.6 KB · Views: 125
  • server.png
    server.png
    131 KB · Views: 151
  • server_top.png
    server_top.png
    93.6 KB · Views: 129
Rechnen wir mal grob durch: 1000 Zugriffe am Tag sind im Schnitt nicht mal ein Zugriff pro Minute! Das sollte ein Pentium2 schaffen!

Ganz klare Konsequenz: An der Hardware liegt es nicht!

Feintuning kannst du komplett lassen, daran liegt es offensichtlich auch nicht. Jede Out-of-theBox Installation schaufelt auch mit ungünstigen Einstellungen wesentlich mehr Requests weg. Wenn du an der eingesetzten Software selbst nicht etwas ganz furchtbar verkonfiguriert hast, bleibt eigentlich nur das Script, welches furchtbar Mist baut.

Mein Tipp: Setzte alle Software auf Default-Config zurück, wirf alle selbst versuchten Optimierungen raus. Richte eine rein statische Seite ein, die du mit Pingdom parallel monitorst. Gibt es einen signifikanten Zusammenhang beider Response-Zeiten liegt es an der VM. Ist die statische Seite unabhängig immer schön schnell, liegt es an deinem Script.
 
Last edited by a moderator:
Nun, du scheinst ja selbst schon erkannt zu haben, dass du ein MySQL-Problem hast. Allerdings wohl eher im Skript als im mysqld selbst - so kaputtkonfigurieren kann man den nämlich eigentlich gar nicht.

Von daher:

Dann habe ich mal nach slow-queries gesucht. Habe mal 4s eingestellt, da ich ja mittlerweile bei einer durchscnitts response Zeit von 11,4s bin.
Vier Sekunden ist schon extrem, ich logge i.d.R. Queries ab 500 ms und dazu Queries, die keine Indizes benutzen. Da solltest du ansetzen und diese Queries optimieren; sie sind mit Sicherheit die Ursache für die lange Ladezeit.

Du könntest die langsamen Queries auch hier posten; einige Datenbank-Experten sind hier vertreten, wobei ich selbst nicht dazu gehöre. ;)
 
Bevor ich diese guten Ansätze mal teste hab ich noch eine Verständnis Frage. Wieso ist denn meine response Time im Durchschnitt jetzt so Mega schlecht geworden nachdem ich die Table_cache und table_cache_definition erhöht habe und gemäß tuning_primer nun im grünen Bereich liege?? Das hätte sich doch nun zumindest etwas verbessern müssen oder?
 
@ PapaBaer
Ich hatte mal eine kleine Webpage für einen Kumpel mit 6-7 Seiten gebastelt mit joomla 2.5. Das habe ich jetzt unter einen Subdomain und einer eigenen Dtaenabank installiert. Habe viele viele schnelle klicks gemacht....das blöde ist....die Seiten wurden alle sehr schnell geladen, keine Probleme mit SQL. Prozessor Leistung war nicht mal ausgelastet.

Response Time lag bei 600ms

Hab da anscheinend ein Problem mit dem Script von dem tollen Unternehmen agriya.com.


Vier Sekunden ist schon extrem, ich logge i.d.R. Queries ab 500 ms und dazu Queries, die keine Indizes benutzen. Da solltest du ansetzen und diese Queries optimieren; sie sind mit Sicherheit die Ursache für die lange Ladezeit.
Seit gestern abend habe ich alles geloggt was länger als 1Sekunde braucht.
Die log Datei hat nun 2 verschieden SQL Abfragen da reingeschrieben. Die eine Abfrage befindet sich auf der Startseite und die andere unter dem Link den ich gestern schon gepostet hatte.

Und nu? Was mach ich denn jetzt???:confused:
Damit leben?
 
Wir hatten mal vor langer Zeit auch ein Script von der Firma agriya am laufen (kotali oder so hieß das glaube ich) und hatten auch viele Probleme in sachen Performance.
Da der Support nicht wirklich helfen wollte (oder konnte) und die Fehler bei uns gesucht hat musste der Kunde dann wohl oder übel auf ein anderes Script umsteigen.

War ein sehr langes hin und her aber die Plattform rennt bis heute. Ich drück dir dennoch die Daumen das du dass in den Griff bekommst.
 
Bei Agriya gibt es in Sachen Service Nichts. Bei mir haben die gesagt, dass nach einem ausführlichen Test alles super läuft. Auch mein Hinweis, dass deren Demo Seite auch grottenschlecht läuft wurde ignoriert.
Ich würde auch gerne ein neues Script kaufen, leider ist die Auswahl sehr klein und das zu finden was ich suche gleich 0.
 
Ich würde auch erstmal empfehlen von Grund auf neu zu installieren. Ich fürchte das System ist bei den Bemühungen zur Optimierung zerbastelt worden.

Btw, hab' ich da richtig in der Prozess-Liste gesehen, dass da noch ein Plesk 9 drauf rennt? Wenn das, das einzige Projekt ist, was auf dem Server läuft, würde ich komplett auf so ein ACP verzichten.

Weiterhin sieht es so aus, als ob PHP als CGI-Variante laufen würde, das ist ebenfalls wenig performant.
 
Ne ich hab Plesk 11 drauf mit Debian. Ich habe den Server erst im Juli oder so aufgesetzt. Plesk 11 wurde mit nginx, apache2 und fastcgi ausgeliefert. So habe ich es dann konfiguriert. Bin mir im Moment auch nicht so sicher ob Nginx die bessere Wahl war.

Viel zerbastelt habe ich da eigentlich nicht. Ich habe mir mal eine Anleitung zum aufsetzen fertig gemacht. Den werde ich hier heute mal posten. Eigentlich denke ich müsste das alles passen.
 
Auch unter Plesk 11 heißt das Verzeichnis immer noch Plesk 9. Ist auf meinem VServer bei Server4You genauso!
 
Habe dort einen vServer Pro X5. Damit läuft alles einwandfrei und auch der Support war mir gegenüber bisher immer sehr gut. Auch beim Wechsel vom X4 auf X5 haben die sich sehr kulant gezeigt, wobei ich mit dem X4 nicht zufrieden war - permanente Stabilitäts- und Speicherprobleme.
Aber über den aktuellen kann ich nichts negatives sagen.

Ich war zwischendrinnen mal kurz bei webtropia - darüber kann ich leider wenig gutes berichten. Aber vielleicht hatte ich dort einfach nur Pech.
 
Den Server hatte ich mir auch ausgesucht für einen Wechsel. Jetzt les ich fast nur noch negatives.

Hat jemand noch eine Idee was ih noch machen könnte?
 
Vier Sekunden ist schon extrem, ich logge i.d.R. Queries ab 500 ms und dazu Queries, die keine Indizes benutzen. Da solltest du ansetzen und diese Queries optimieren; sie sind mit Sicherheit die Ursache für die lange Ladezeit.

Dazu habe ich mal ne Frage....was ist denn das log-queries-not-using-indexes?

Ich habe das heute mal enabled. Da sind jetzt schon 300queries zusammen gekommen, die länger als 1 Sekunde brauchen.
Tu mich im Moment schwer, dass was er in die Logs schreibt auch in meinen Script zu finden. Gibt es einen Weg, das rauszubekommen welche Zeile und welche Datei das steht?



Ich habe vor 3Std den join_buffer_size erhöht in der my.cnf. Die Response Zeit ist seitdem runter auf 2-3s. Ist ja schon mal was. Hab auch seitdem das Gefühl, dass meine Seite richtig flüssig läuft. :p

Ich hatte heute auch den ganzen Tag noch keinen Server Aussetzer. Premiere:D
 
Dazu habe ich mal ne Frage....was ist denn das log-queries-not-using-indexes?

[...]

Tu mich im Moment schwer, dass was er in die Logs schreibt auch in meinen Script zu finden. Gibt es einen Weg, das rauszubekommen welche Zeile und welche Datei das steht?
Zu erstem: SQL-Statements, die keine Indizes benutzen. Sollte man sich anschauen und ggf. nachträglich welche anlegen.

Zu zweitem: Jein. In aller Regel werden Klassen-Bibliotheken/Frameworks benutzt, welche dann aus den Eingabeparametern das tatsächliche SQL-Statement zusammenbasteln.

D.h. letztlich Reverse-Engineering also du musst das Script als auch die Datenbankstruktur verstehen, um Optimierungen vornehmen zu können. Für Scripte, die man selbst geschrieben hat, geht das noch relativ einfach. Bei fremden Code ist das ganze ungleich schwieriger und häufig extrem zeitaufwendig. Dabei sind auch die Lizenzbedingungen zu beachten.
 
Oft werden slow-queries dadurch verursacht dass nach Feldern mit dynamischer Länge (BLOB,TEXT) sortiert/joined wird und somit die zu joinenden Tabellen gelesen und in eine temporäre Tabelle auf der Platte geschrieben werden.
Dies ist natürlich sehr zeitaufwendig und zumal bei EXT4-Dateisystemen mit Default-Mountparameter ein Grauen.

Entsprechende EXT4-Parameter (dazu gibt es hier mehrere Threads, Stichwort barrier=0) sowie der Wechsel zu Percona MariaDB und evtl ein Tmpfs helfen hier einer schlecht programmierten Software viel.
 
Also die hälfte von dem was ihr geschrieben habt hab ich nicht verstanden :) Gerafft hab ich aber, dass ich dann die Finger von den Slow queries ohne indizens lassen sollte.

Die anderen Slow Queries krieg ich vielleicht noch hin.

Danke nochmal an alle die sich an meinem Problem beteiligt haben. Ich werde den Server nochmal sauber neu aufsetzen aber werde mich wieder für apache2 entscheiden ohne Nginx.
 
Muss mich nochmal melden. Echt am verzweifeln. Seitdem ich mit Tuning-Primera.sh die Werte in der my.cnf geändert habe, bekomme ich die response zeit von durschnittlich 12s nicht mehr runter. Hab jetzt gestern table cache Definition und Tablet Cache auf 2048 runtergesetzt. Bin im grünen Bereich aber gebessert hat sich nichts. In meiner my.cnf war auch table cache definition garnicht vorhanden. Ich hab es selbst da eingefügt. Könnte es vielleicht daran liegen. Jetzt kann es ja nicht nur an den slow_queries liegen. Das waren aber nicht soviele. Was kann ich noch machen?
 
Back
Top