Serverperformance sinkt mit zunehmender Laufzeit

Hallo zusammen,
wir haben mehrere MySQL5-Server (unter großer Last) am laufen, was
soweit auch ganz gut funktioniert. Wenn die Server allerdings mehrer
Tage ohne Neustart durchlaufen steigt die Serverload in den Peak-Zeiten
überdurchschnittlich weit an.
Wenn wir die SQL-Server (beispielsweise in der Nacht vorher) neu starten
gibt es diese Probleme hingegen nicht.

Hat jemand eine Idee woran das liegen könnte? Macht MySQL beim starten
vielleicht noch irgendwas "tolles" was Performance fördert?

Grüße Claus

Re: Serverperformance sinkt mit zunehmender Laufzeit

Andreas
--
Andreas Kretschmer
Linux - weil ich es mir wert bin!
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
Deutsche PostgreSQL User Group: http://pgug.de

Re: Serverperformance sinkt mit zunehmender Laufzeit

Andreas Kretschmer wrote:

> Vielleicht leakt der Speicher. Welches OS?

Debian Stable mit MySQL5 aus den Backports

Re: Serverperformance sinkt mit zunehmender Laufzeit

Andreas
--
Andreas Kretschmer
Linux - weil ich es mir wert bin!
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
Deutsche PostgreSQL User Group: http://pgug.de

Re: Serverperformance sinkt mit zunehmender Laufzeit

=?ISO-8859-1?Q?Claus_Näveke?= wrote:

> wir haben mehrere MySQL5-Server (unter großer Last) am laufen, was
> soweit auch ganz gut funktioniert. Wenn die Server allerdings mehrer
> Tage ohne Neustart durchlaufen steigt die Serverload in den Peak-Zeiten
> überdurchschnittlich weit an.

Definiere "Serverload". Sprichst du vom "Load" Parameter aka "Anzahl
lauffähiger Prozesse in der Scheduler Queue"?

Das könnte durchaus ein positiver Effekt sein. Wenn der Server längere
Zeit gelaufen ist, sind alle Caches warm und es wird weniger Zeit mit
dem Warten auf die Festplatte vertrödelt. Dafür wird jetzt die CPU-Zeit
die knappste Ressource.

> Wenn wir die SQL-Server (beispielsweise in der Nacht vorher) neu starten
> gibt es diese Probleme hingegen nicht.

Sind es denn *Probleme*? Wie sieht denn der Durchsatz aus (Queries pro
Minute)? Daß mit steigender Last = Anzahl konkurrierender Anfragen die
Antwortzeit pro Query höher wird, ist normal. Entscheidend ist aber der
Durchsatz = Anzahl beantworteter Anfragen / Zeitintervall.

Normalerweise steigt der Durchsatz mit steigender Last an, nähert sich
asymptotisch dem Maximum und fängt irgendwann wieder an zu fallen
(Überlastung). Solange du nicht in den letzteren Bereich kommst, ist
alles OK.

Eine mittelgroße Zahl für die Load ist nicht unbedingt ein schlechtes
Zeichen. Wenn Load > Anzahl Prozessoren, ist das ein Hinweis, daß man
CPU-bound ist (daß mehr oder schnellere Prozessoren also höheren
Durchsatz bringen würden). Linux Kernel vor 2.6 würde ich nicht
dauerhaft mit einer Load > 5 * Anzahl CPUs betreiben wollen. 2.6.x ist
nochmal deutlich toleranter (der O(1) Scheduler ist fein).


XL

Re: Serverperformance sinkt mit zunehmender Laufzeit

Axel Schwenke wrote:

> Definiere "Serverload". Sprichst du vom "Load" Parameter aka "Anzahl
> lauffähiger Prozesse in der Scheduler Queue"?

Die "normale" Load, die einem das Linux-System ausspuckt.
>
> Das könnte durchaus ein positiver Effekt sein. Wenn der Server längere
> Zeit gelaufen ist, sind alle Caches warm und es wird weniger Zeit mit
> dem Warten auf die Festplatte vertrödelt. Dafür wird jetzt die CPU-Zeit
> die knappste Ressource.

IO-Wait wird doch auch mit in die Load gerechnet, oder?

>
> Sind es denn *Probleme*? Wie sieht denn der Durchsatz aus (Queries pro
> Minute)? Daß mit steigender Last = Anzahl konkurrierender Anfragen die
> Antwortzeit pro Query höher wird, ist normal. Entscheidend ist aber der
> Durchsatz = Anzahl beantworteter Anfragen / Zeitintervall.

Durchsatz liegt bei 300 Querys/s im Gesamtdurchschnitt. Genaue zahlen
hab ich leider nicht zur Hand, aber die Ladezeiten werden DEUTLICH
langsamer, wenn der Server bereits mehrere Tage läuft. Nach einem
Neustart spürt man auch bei sehr großen Nutzerzahlen kaum Verzögerungen.
>
> Normalerweise steigt der Durchsatz mit steigender Last an, nähert sich
> asymptotisch dem Maximum und fängt irgendwann wieder an zu fallen
> (Überlastung). Solange du nicht in den letzteren Bereich kommst, ist
> alles OK.

Genau das scheint aber bei längerer Laufzeit der Fall zu sein.
>
> Eine mittelgroße Zahl für die Load ist nicht unbedingt ein schlechtes
> Zeichen. Wenn Load > Anzahl Prozessoren, ist das ein Hinweis, daß man
> CPU-bound ist (daß mehr oder schnellere Prozessoren also höheren
> Durchsatz bringen würden). Linux Kernel vor 2.6 würde ich nicht
> dauerhaft mit einer Load > 5 * Anzahl CPUs betreiben wollen. 2.6.x ist
> nochmal deutlich toleranter (der O(1) Scheduler ist fein).

Da hätte ich vielleicht ein paar Zahlen anbringen sollen:
Sowohl auf Single-, als auch auf Dual-Xeon Maschinen geht die Load
peakweise über 20 teils deutlich über 30. Das System "läuft" dann zwar
noch, aber seeeehr langsam.

Grüße Claus

Re: Serverperformance sinkt mit zunehmender Laufzeit

=?ISO-8859-1?Q?Claus_Näveke?= wrote:
> Axel Schwenke wrote:
>
>> Wenn der Server längere
>> Zeit gelaufen ist, sind alle Caches warm und es wird weniger Zeit mit
>> dem Warten auf die Festplatte vertrödelt. Dafür wird jetzt die CPU-Zeit
>> die knappste Ressource.
>
> IO-Wait wird doch auch mit in die Load gerechnet, oder?

Normal nicht. Außerdem ist I/O-Wait nicht gleich I/O-Wait. Das, was
der Linux-Kernel als I/O-Wait ausweist, sind CPU-Zyklen. die per busy
waiting (im Prinzip "Flag pollen") im Kernel verbraten werden. Das Gros
der Gerätetreiber verwendet allerdings Interrupts statt Waiting. Seit
2.6 kann Linux das auch schön als HW-IRQ und Soft-IRQ ausweisen.

Prozesse, die auf I/O warten, sind in der Scheduler Queue als
"suspended" markiert, erhöhen also nicht die Load Kennzahl.

>> Sind es denn *Probleme*? Wie sieht denn der Durchsatz aus (Queries pro
>> Minute)? Daß mit steigender Last = Anzahl konkurrierender Anfragen die
>> Antwortzeit pro Query höher wird, ist normal. Entscheidend ist aber der
>> Durchsatz = Anzahl beantworteter Anfragen / Zeitintervall.
>
> Durchsatz liegt bei 300 Querys/s im Gesamtdurchschnitt. Genaue zahlen
> hab ich leider nicht zur Hand, aber die Ladezeiten werden DEUTLICH
> langsamer, wenn der Server bereits mehrere Tage läuft. Nach einem
> Neustart spürt man auch bei sehr großen Nutzerzahlen kaum Verzögerungen.

Was meinst du mit "Ladezeiten"? Ich rate: die Zeit, die dein Webserver
braucht, um einen HTTP-Request zu beantworten?

Für eine Analyse fehlen Daten. Das Minimum, was du aufzeichnen müßtest,
wären CPU-Last (aka Load), CPU-Zyklen-Verwendung (user/sys/iowait/idle),
Durchsatz (Requests/Minute), Responsezeit. Und das nicht nur als
globaler Mittelwert, sondern z.B. jede Minute.

Ich habe mir vor längerer Zeit mal ein Monitoring-Tool dafür
geschrieben. Das erzeugt z.B. solche Grafiken:

http://24days.de/~schwenke/asing/example/linux/ (Webserver, Replikat)
http://24days.de/~schwenke/asing/example/solaris/ (MySQL-Server)

(wenn du basteln willst: da liegt auch ein tar.gz)

>> Normalerweise steigt der Durchsatz mit steigender Last an, nähert sich
>> asymptotisch dem Maximum und fängt irgendwann wieder an zu fallen
>> (Überlastung). Solange du nicht in den letzteren Bereich kommst, ist
>> alles OK.
>
> Genau das scheint aber bei längerer Laufzeit der Fall zu sein.

Das von mir beschriebene Verhalten gilt für ansteigende Belastung,
nicht für fortschreitende Zeit. Das einzige, was sich mit fortschrei-
tender Zeit ändern sollte, ist die Belegung der diversen Caches.
Normalerweise ändert sich das zum Guten, weil die Cache-Belegungs-
strategie (typisch LRU) häufig benutzte Daten im Cache hält.

Wenn allerdings deine Caches zu groß sind, spielen sie das Verdrängungs-
spiel mit z.B. dem page cache des Linux Kernels und das Gesamtsystem
wird über die Zeit ineffizienter. Füge zu den o.g. Datenquellen also
noch die RAM-Belegung hinzu. Außerdem die Effizienz des MySQL
key_buffers (für MyISAM) bzw. die InnoDB-Statistik über
gelesene/geschriebene/erzeugte Pages.

Ebenfalls sehr nützlich sind die Statistiken der Massenspeicher. Für
Festplatten ist weniger der Durchsatz interessant als vielmehr die
Anzahl I/O-Zugriffe pro Sekunde. Ganz eindeutig ist der "util" Wert
den dir iostat anzeigt.

Aber als erstes solltest du mal die Speichernutzung anschauen. Wenn
das eine MyISAM-mostly Datenbank ist, solltest du 30-50% des RAMs für
Linux' Page Cache frei lassen. Immerhin ist das der einzige Cache für
die Daten. Den key_buffer nicht größer machen als nötig, ab 95% Hits
(d.h. key_reads < key_read_requests/20) bringt eine weitere
Vergrößerung kaum noch was. Den query_cache solltest du ganz genau
beobachten. Manchmal bringt der sehr viel (z.B. auf o.g. Webserver)
manchmal aber auch gar nichts.

>> Eine mittelgroße Zahl für die Load ist nicht unbedingt ein schlechtes
>> Zeichen. ... Linux Kernel vor 2.6 würde ich nicht
>> dauerhaft mit einer Load > 5 * Anzahl CPUs betreiben wollen. 2.6.x ist
>> nochmal deutlich toleranter (der O(1) Scheduler ist fein).
>
> Da hätte ich vielleicht ein paar Zahlen anbringen sollen:
> Sowohl auf Single-, als auch auf Dual-Xeon Maschinen geht die Load
> peakweise über 20 teils deutlich über 30.

Du schriebst "Debian stale"? Das wäre jetzt Woody? Kernel 2.6?
Dann ist das noch nicht unbedingt kritisch. Aber auf jeden Fall bist
du schon hinter dem Performance-Peak.

> Das System "läuft" dann zwar noch, aber seeeehr langsam.

Kann ich mir lebhaft vorstellen.


XL