Tuning: Server beobachten @ huschi.net

Datenbank-Server

ID #1299 Tuning: Server beobachten

Problem:

Simple und eher subjektive Beobachtung: Der Server ist langsam.
Aber dennoch will man nun wissen warum.

Häufig tappt man relativ im Dunkeln, schaut sich mal eine Ausgabe von top an und sieht entweder nichts auffälliges, oder interpretiert die Ausgabe falsch. (Z.B.: "Ich habe soviele Apache-Prozesse! Kein Wunder das der Speicher ausgeht...")

Beobachtung:

Wenn das Symptom langsamer Server gerade akut ist, wird als erstes der aktuelle Zustand aufgenommen.
Bei anhaltenden Symptomen kommt man an einer lang zeitlichen Beobachtung nicht vorbei.
Und wenn der Server trotz Optimierung und optimaler Speicherauslastung nicht zufrieden mit der Serverleistung ist, ist nun mal der nächste Schritt ein neuer Server mit mehr RAM und besserer CPU.

Typische Ansätze

Erster Schritt ist immer der Aufruf von top. Dort hat man die aktuelle Situation schön in einem Blick. (Bitte lesen: Interpretation der Ausgabe!)
Dabei werfen wir vorallem einen Blick auf die Load. Denn diese Werte geben bereits Auskunft, ob es sich um ein Langzeit-Phänomen handelt oder nicht. Wenn die Load15 dauerhaft über 1.00 liegt, ist der Server wirklich ausgelastet.
Achtung: Load ist nicht gleich CPU-Auslastung! Ein hoher Load kann auch durch IO-Waits (also z.B. warten auf die Festplatte) entstehen.

Weiterer wichtige Werte sind die WA (== wait for IO) und der gebrauchte Swap-Speicher. Ein WA von 100% heißt z.B., daß die Festplatte ziemlich viel zu tun hat. Wenn dies nicht gerade mit dem Swap zusammen hängt, könnte es ein größerer Download/Upload oder eine Datenbank-Abfrage sein.

Zweiter Schritt ist meist ein Blick auf den Webserver:
Hat der Apache zuviele Prozesse? Nutzt er zuviel Speicher? (Evtl. soviel, daß der Server swappen muß?)
Zur Überwachung geeignete Tools gibt es außer dem Apache eigenen mod_status nicht. Manchmal ließt man etwas von apachetop, aber es hilft nicht bei der Optimierung. Denn apachetop bezieht seine Informationen ausschließlich aus Logfiles. Diese werden aber bekanntlich erst geschrieben, wenn der Request abgearbeitet ist. Dadurch erhält man also keine Info's über die aktuelle Auslastung des Apache sondern immer nur Daten über die kürzliche Vergangenheit.
(Siehe auch: Hochleistungs-Apache: Performance-Tuning)

Dritte Vermutung liegt dann auf dem Datenbank-Server. Größere Datenbanken verbrauchen auch mehr IO-Waits und natürlich auch CPU-Zeit. Hier kann man z.B. mit mehr zugeteiltem Speicher schon einiges Bewirken.
Um sich einen Überblick über die aktuellen MySQL-Prozesse zu bilden, kann man z.B. das Tool mytop (Projektseite bei Freshmeat) nutzen. Es stellt übersichtlich die aktuellen Daten von SHOW STATUS und SHOW PROCESSLIST dar.
(Siehe auch : MySQL-Tuning)

Auf den vierten typischen Übeltäter kommen die meisten erst gar nicht: der Mailserver.
Wenn viele Emails abzuarbeiten sind, werden auch mehrere Prozesse dafür gestartet die alle ihren Speicher anfordern. Sowohl Postfix als auch Qmail sind entsprechend skalierbar (also einzuschränken, bzw. zu erweitern).
Wobei man hier immer zwei Seiten beobachten muß:
a) Mail-Ausgang
b) Mail-Eingang

Während der Mail-Ausgang nur Emails verschickt und daher eher nur kurzzeitig einen Prozess pro Email startet, hängt am Mail-Eingang meist eine ganze Reihe an Prozessen: der SMTP-Dämon, der Spam-Filter, der Viren-Filter und der lokale Mail-Delivery-Agent (MDA). Wenn man also z.B. bis zu 20 Email gleichzeitig empfangen lassen will, muß man auch ausreichend Power haben um diese gleichzeitig auf Spam und Viren untersuchen zu lassen.

Langzeit Beobachtung:

Langzeit-Beobachtung ist ein wesentlicher Vorgang bei der Server-Optimierung. Hierzu nimmt man entsprechende Scripte wie z.B. sysstat oder graphische RRD-Tools wie MRTG oder für Webmin das Modul webminstat.
Anhand des Verlaufes kann man häufig feststellen, ob diese hohe Auslastung Periodisch auftreten, wann sie auftreten und im Vergleich mit den Weblog-Analyser-Tools (Webalizer, AWstats) erkennt man evtl. auch woher diese Auslastungen kommen.