nicht angemeldet
HI, Alexander
Das spricht für eine organisch gewachsene Anwendung ("Krebsgeschwür"), die jetzt plötzlich attraktiv geworden ist.
So plötzlich ist es nicht gewachsen. Google mag meine Inhalte...
Du brauchst jemanden, der sich WIRKLICH damit auskennt.
Hab keinen ;O) und mit Linux kenne ich mich nur oberflächlich aus.
Es geht nicht um Größe, es geht um Geschwindigkeit. Wenn Deine Anwendung 80% der Zeit mit dem Shared Memory rumfummelt, obwohl es nur 10KByte groß ist, ist es Dein Problem.
1 mal lesen + 1 mal schreiben pro Zugriff im Ram das sollte den Server nicht plattmachen.
Finde den Bottleneck.
JA ABER WO??? Oder besser gesagt wie??
Messen, messen, messen, und nochmal messen.
Kannst Du mir bitte sagen wie! Programme die sowas unter Linux das machen sind mir nicht bekannt.
Hast Du passende Indices in der DB angelegt? Ich denke schon.
Hast Du oder hast Du nicht? Nicht raten, prüfen!
Die Prozessliste sieht gut aus.
Das ist der falsche Meßwert. Die Prozessliste zeigt Dir bestenfalls kumulierte Symptome.
Hast Du je eine Liste der am häufigsten und am längsten laufenden SQL-Queries? Wenn nein, warum nicht?
Nein, das habe ich mir auch schon überlegt. Gibt es zum Auswerten der Mysql Querie logs Programme. Bzw. wiekann ich das bewerkstelligen?
Hast Du überprüft, auf welchen Spalten und Spaltenkombinationen die Queries laufen? Und das für diese schweren Fälle passende Indices vorhanden sind?
Zumindest das was mir bekannt ist Explain Select .......... usw.
Mysql liegt bei 65% von der CPU.
Das bestätigt meine Vorurteile. ;-) Ich halte das für wesentlich zu viel.
Meine Vermutung ist auch das es an Mysql liegen kann. Mir fehlen einfach Vergleichswerte.
Laufzeit-Informationen Dieser MySQL-Server läuft bereits 0 Tage, 14 Stunden, 14 Minuten und 15 Sekunden. Er wurde am 12. Januar 2009 um 20:49 gestartet.
Abfragestatistik: Seit seinem Start wurden 1.608.278 Abfragen an diesen MySQL-Server gesandt. Insgesamt ø pro Stunde ø pro Minute ø pro Sekunde 1.608.278 112.960,70 1.882,68 31,38
Abfrageart ø pro Stunde % admin commands 186 13,06 0,01 % alter table 0 0,00 0,00 % analyze 0 0,00 0,00 % backup table 0 0,00 0,00 % begin 0 0,00 0,00 % change db 155.905 10.950,31 10,69 % change master 0 0,00 0,00 % check 470 33,01 0,03 % commit 0 0,00 0,00 % create db 0 0,00 0,00 % create function 0 0,00 0,00 % create index 0 0,00 0,00 % create table 0 0,00 0,00 % delete 69.747 4.898,82 4,78 % delete multi 0 0,00 0,00 % drop db 0 0,00 0,00 % drop function 0 0,00 0,00 % drop index 0 0,00 0,00 % drop table 0 0,00 0,00 % flush 0 0,00 0,00 % grant 0 0,00 0,00 % ha close 0 0,00 0,00 % ha open 0 0,00 0,00 % ha read 0 0,00 0,00 % insert 356.186 25.017,45 24,43 % insert select 0 0,00 0,00 % kill 0 0,00 0,00 % load 0 0,00 0,00 % load master data 0 0,00 0,00 % load master table 0 0,00 0,00 % lock tables 0 0,00 0,00 % optimize 20.824 1.462,62 1,43 % purge 0 0,00 0,00 % rename table 0 0,00 0,00 % Abfrageart ø pro Stunde % repair 0 0,00 0,00 % replace 0 0,00 0,00 % replace select 0 0,00 0,00 % reset 0 0,00 0,00 % restore table 0 0,00 0,00 % revoke 0 0,00 0,00 % rollback 0 0,00 0,00 % savepoint 0 0,00 0,00 % select 398.842 28.013,49 27,35 % set option 0 0,00 0,00 % show binlog events 0 0,00 0,00 % show binlogs 2 0,14 0,00 % show create 0 0,00 0,00 % show databases 4 0,28 0,00 % show fields 0 0,00 0,00 % show grants 0 0,00 0,00 % show keys 0 0,00 0,00 % show logs 0 0,00 0,00 % show master status 0 0,00 0,00 % show new master 0 0,00 0,00 % show open tables 0 0,00 0,00 % show processlist 1 0,07 0,00 % show slave hosts 0 0,00 0,00 % show slave status 0 0,00 0,00 % show status 3 0,21 0,00 % show innodb status 0 0,00 0,00 % show tables 60 4,21 0,00 % show variables 1 0,07 0,00 % slave start 0 0,00 0,00 % slave stop 0 0,00 0,00 % truncate 0 0,00 0,00 % unlock tables 0 0,00 0,00 % update 109.894 7.718,63 7,54 %
Weitere Statusvariablen Variable Wert Created tmp disk tables 99375 Created tmp tables 129594 Created tmp files 9 Delayed insert threads 0 Delayed writes 0 Delayed errors 0 Flush commands 1 Handler commit 0 Handler delete 1550 Handler read first 2543 Handler read key 1978625 Handler read next 635034987 Handler read prev 71805 Handler read rnd 4532770 Handler read rnd next 2701195363 Handler rollback 0 Handler update 437814 Handler write 3654345495 Key blocks used 124690 Key read requests 529305367 Variable Wert Key reads 244033 Key write requests 297290 Key writes 202698 Max used connections 46 Not flushed key blocks 0 Not flushed delayed rows 0 Open tables 541 Open files 1006 Open streams 0 Opened tables 548 Qcache queries in cache 46987 Qcache inserts 244529 Qcache hits 347917 Qcache lowmem prunes 117797 Qcache not cached 145059 Qcache free memory 30957920 Qcache free blocks 9253 Qcache total blocks 107411 Rpl status NULL Variable Wert Select full join 289 Select full range join 0 Select range 127462 Select range check 0 Select scan 132134 Slave open temp tables 0 Slave running OFF Slow launch threads 0 Slow queries 184 Sort merge passes 3 Sort range 117899 Sort rows 4594592 Sort scan 147808 Table locks immediate 607781 Table locks waited 2376 Threads cached 17 Threads created 95 Threads connected 9 Threads running 6
Speicherfresser (Counter usw.) habe ich vernichtet. Ich dachte erst das es daran liegt.
Definitiv nicht. Deine Load ist um 500% bis 1000% zu hoch, weil zu viele Prozesse gleichzeitig laufen müssen, was darauf zurückzuführen ist, dass Du die Requests nicht SCHNELL genug abarbeitst.
Werden statische Resourcen schnell ausgeliefert? Dann ist der Apache aus der Nummer raus, und das Problem ist deine Anwendung.
Evtl. kann es an mod_rewrite liegen. PHP > *.html
Nichr raten, messen, messen, messen.
Ja womit und wie?
Je komplexer deine Rewrite Rules sind, desto mehr Zeit muß der Apache dort verbrennen. Wenn Du nur ein oder zwei einfache Regeln hast, ist es nicht mod_rewrite.
Warum willst Du Deine Anwendung unbedingt mit einem ".html" am Ende der URL ausliefern? Dem Browser ist das Ende der URL vollkommen egal, umd dem Server macht es weniger Arbeit, wenn Du auf so einen Unsinn verzichtest.
Geht nicht bin auch ein wenig SEO
Nutzt Du Caching-Funktionen in Deiner Anwendung? Cachst Du die Sachen, die lange dauern, oder was Dir gerade einfiel? Übertreibst Du es mit dem Caching?
Ja! ca. 24 Stunden als *.zip File. Mysql Cache ist on. Hauptdatenbänke im Cache ohne upload und co.
Du hast keine Ahnung, wovon ich rede, oder?
Kann schon sein. Bei der Entwicklung der Seite habe ich mir überlegt wenn ich Datenbankabfragen der letzten 24h als File bzw. fertiges *.html im Cache Ordner lege gewinne ich Zeit und entlaste den MysqlServer.
Wenn Du 20x eine Liste aller Uploads eines Users brauchst, machst Du dann 20x "SELECT FROM UPLOADS WHERE userid=x"? Oder machst Du den SELECT nur beim ersten Mal und merkst Dir das Ergebnis für die nächsten 19 Mal?
Das macht der Mysql Cache
Was außer Apache und MySQL benutzt Du? PHP
Version? Libraries? Frameworks?
Da habe ich keine Ahnung was Du meinst. Ich nutze so gut wie keine fertigen Programme.
MySQL Version 4.0.23_Debian-7 Php Version 4.3.10,
Ein Update möchte ich nicht weil ich nicht weis ob dann noch alles läuft!
Noch eine Überlegung:
(D)ein Webserver hat genau dann alle Hände voll zu tun, wenn ein Request kommt: Request verarbeiten, PHP-Interpreter starten, PHP Interpretieren, Datenbank-Abfragen machen, Ergebnis ausrechnen, Ergebnis zurückschreiben, Logs schreiben. Und all das passiert, grob betrachtet, gleichzeitig. In dem Moment, in dem Deine Anwendung die CPU braucht, will auch die DB reichlich CPU haben. Und um RAM und Festplatte streiten sich auch beide.
Daraus folgt: Du könntest die Datenbank auf eine separate Maschine packen, so dass sich DB und Applikation bei CPU, RAM und HDD nicht gegenseitig im Weg stehen. Dann wird allerdings die Netzwerkverbindung u.U. ein Bottleneck.
Ich habe einen managed Server weil ich kein Linux Mensch bin.
Ein Patch-Kabel direkt zwischen den Servern wäre optimal, aber eine gewitchte Umgebung tut's meistens auch. Je schneller das Netzwerk ist, um so besser. 100 MBit/s sollten es schon sein, 1 GByte/s wäre schöner. Und die Absicherung wird natürlich extrem wichtig. Ein dediziertes Kabel zwischen Web- und DB-Server mit IP-Adressen aus dem privaten bereich (z.B. 192.168.42.1 und 192.168.42.2) wäre optimal und absolut dicht, wenn Du auf einen zweiten Mietserver gehst, muß die DB sich selbst schützen, damit nur der Webserver Zugriff hat.
Es gibt natürlich auch andere Optimierungsmöglichkeiten: Es wäre blöd, den PHP-Code Deiner Anwendung für jeden Request komplett neu zu parsen und zu interpretieren, obwohl sich der Code nicht ändert. Deswegen gibt es gerade für PHP einiges an Software, um PHP zu beschleunigen, in der Regel dadurch, dass ein permanent laufender Prozess den Code einmal einliest und den geparsten Code im Speicher hält, um so pro Request das Parsen einzusparen. Google ist Dein Freund, http://en.wikipedia.org/wiki/PHP_accelerator ist ein brauchbarer Anfang.
»» Habe ich mir mal vor längerer Zeit angesehen. Aber irgendwie sind damals nur die kostenpflichtigen Versionen stabil gewesen.
Und dann bleibt natürlich noch Deine Anwendung. Überlege, was Du jedes Mal neu berechnen mußt und was Du vorberechnen kannst. Vermeide, ALLE Resourcen per PHP auszuliefern. Dateien auf dem Webserver durch PHP zu schleusen ist in den meisten Fällen unsinnig. Javascripte und Stylesheets sowie die meisten (alle) Bilder kann der Webserver ohne PHP wesentlich schneller ausliefern.
Passen Deine Datenformate zu Deiner Anwendung? Wenn Du für jeden Request erst einmal ein 20 MByte großes XML-File durchkauen mußt, hast Du Deine Daten falsch abgelegt. Berechnet Deine Anwendung irgendwelche Sachen auf Verdacht bzw. auf Vorrat? Raus damit, wenn die Berechnung in den meisten Fällen nicht benötigt wird.
Das ist nicht soeinfach umzusetzen. Bei den Anwendungen kann kein reines Filesystem aus statischen Seiten Anwendung finden.
Danke für Deine Ausführungen.
Und nochmals eine Frage welche Programme / Befehle eignen sich unter Linux / Php zum finden von Laufzeitintensiven Prozessen.
Also eine Auswertung / Überwachung von:
top
1546 nobody 16 0 143m 4912 3540 R 19.1 0.2 0:00.50 0 /usr/sbin/httpd -k restart
Simone