Server Systemauslastung Normalwerte

[Alexander (HH)]

Moin Moin!

Das sollte einen Webserver völlig kalt lassen. Das ist noch nicht einmal einer pro Sekunde.

Naja, die Probleme haben mit der Steigerung der Besucherzahlen erst angefangen. Ca. 3 Jahre ging auch alles super..

Das spricht für eine organisch gewachsene Anwendung ("Krebsgeschwür"), die jetzt plötzlich attraktiv geworden ist.

Du brauchst jemanden, der sich WIRKLICH damit auskennt.

Ja, das mache ich schon! Im Shared Memory Bereich schreibe ich Seitenzugriffe mit... usw.

Machst Du Dir bzw. dem Server da zu viel Arbeit?

... denke nicht das Segment ist nicht Groß

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.

Finde den Bottleneck.

JA ABER WO??? Oder besser gesagt wie??

Messen, messen, messen, und nochmal messen.

Der Server läuft immer im Roten Bereich sobald User auf meine Seiten kommen.

Dann schmeiß die User raus! ;-)

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?

Hast Du überprüft, auf welchen Spalten und Spaltenkombinationen die Queries laufen? Und das für diese schweren Fälle passende Indices vorhanden sind?

Mysql liegt bei 65% von der CPU.

Das bestätigt meine Vorurteile. ;-)
Ich halte das für wesentlich zu viel.

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.

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.

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?

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?

Was außer Apache und MySQL benutzt Du?
PHP

Version? Libraries? Frameworks?

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. 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.

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.

Alexander