Hoher IO Load ubuntu flush-8:0

Y

yago

Member
Hallo,

ich bin vor kurzem von Debian 6 auf ubuntu 12.04 LTS umgestiegen.
Seitdem hat der Server eine extrem hohe Last (meistens über 20.0), auch wenn gerade nicht viele Zugriffe sind bzw der Server nicht viel zu tun hat.

Auf dem Server läuft nginx + php5 fpm.
Da es sich um eine Webseite handelt, wo Videos hochgeladen werden, laufen auch diverse ffmpeg Prozesse.

Mittels iotop habe ich festgestellt, dass ein Prozess immer ganz oben mit 99% auftaucht, es handelt sich um flush-8:0.
Gesucht nach dem Problem habe ich auch schon, bei manchen ist wohl ein bug in php-apc schuld, das benutze ich aber garnicht.

Hardware ist ein Dell PowerEdge R210 II.
2 x 2TB SAS 7,200 RPM Raid0 (H200 Raid Controller)

Unter Debian 6 trat dieses Problem nie auf, und die Seitenaufrufe/Besucherzahlen haben sich seit dem Wechsel nicht wirklich verändert.
Und die Konfiguration der einzelnen Dienste auch nicht.

Was kann ich tun, und warum trat dieses Problem vorher unter debian nicht auf?

Viele Grüße,
yago
 
Hallo Yago,

Poste doch mal den Output von
iostat -x 10 3

Benutzt Du ext4? Hat dein Raid-Controller eine BBU o.ä? Dann probier es mal mit der Mount-Option 'nobarrier'.

Zur Erklärung: am IO-Subsystem hat sich zwischen den Kernel-Versionen viel getan, insbesondere was die Zuverlässigkeit angeht. ext4 benutzt write barriers, lvm bzw. der device mapper verschluckt sie nicht mehr usw.

Wenn jetzt die write policy deines Controllers auf write through steht bricht die IO-Performance beim Schreiben ein.

schöne Grüße,
Nils
 
Stimmt, man sollte wissen was man tut :-)

Aus
http://kernel.org/doc/Documentation/filesystems/ext4.txt

Code: 
barrier=<0|1(*)>	This enables/disables the use of write barriers in
barrier(*)		the jbd code.  barrier=0 disables, barrier=1 enables.
nobarrier		This also requires an IO stack which can support
			barriers, and if jbd gets an error on a barrier
			write, it will disable again with a warning.
			Write barriers enforce proper on-disk ordering
			of journal commits, making volatile disk write caches
			safe to use, at some performance penalty.  If
			your disks are battery-backed in one way or another,
			disabling barriers may safely improve performance.
			The mount options "barrier" and "nobarrier" can
			also be used to enable or disable barriers, for
			consistency with other ext4 mount options.

Ich empfehle 'nobarrier' ja nicht ohne Grund nur unter der Vorraussetzung 'mit BBU'.

schöne Grüße,
Nils
 
Danke für euere Antworten.

Es handelt sich in der Tat um ext4.
Der Raidcontroller hat keinen Cache.

Im Moment ist die Last nicht ganz so hoch (~10.0), flush-8:0 taucht aber dennoch in iotop wieder ganz oben mit 99% auf.
Hier ist die Ausgabe von iostat:

root@cs2:~# iostat -x 10 3
Linux 3.2.0-29-generic 28/11/12 _x86_64_ (8 CPU)

avg-cpu: %user %nice %system %iowait %steal %idle
23.67 0.00 2.43 3.79 0.00 70.10

Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 4.91 13.31 55.73 21.23 4040.59 8222.78 318.67 3.91 50.81 14.30 146.63 3.72 28.63

avg-cpu: %user %nice %system %iowait %steal %idle
30.87 0.00 1.79 19.86 0.00 47.48

Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 8.70 15.70 131.90 57.30 5004.00 26952.40 337.81 96.40 472.36 14.95 1525.28 4.14 78.28

avg-cpu: %user %nice %system %iowait %steal %idle
23.39 0.00 1.72 11.67 0.00 63.22

Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 14.40 17.00 75.00 58.40 5524.80 26935.60 486.66 54.73 462.98 23.06 1027.96 4.64 61.96
Click to expand...

Da der controller keinen Cache hat kommt nobarrier ja eher nicht in Frage.
Gibt es sonst noch etwas das ich tun könnte?
 
Gerade beim Linux-Kernel gilt: Documentation always lags behind.
Ich zitiere nochmal aus obigem G+ des Ext4-Hauptentwicklers:
In general, you should use ext4 with the default mount options unless you really are an expert and know what you are doing.
Click to expand...
Es mag ja sein, dass Du "really are an expert and know what you are doing", aber der Fragesteller hier ist es nicht und kann daher die möglichen Folgen gar nicht abschätzen. Ebensowenig können es viele der Mitleser hier, weshalb eine derartige Empfehlung Deinerseits sowohl für den Fragesteller als auch Dritte gefährlich ist.

Eine BBU hilft leider nicht immer und kann durch die dort üblichen Lügen der Firmware gar das Problem noch verstärken.

Just my two cent, nicht das später jemand behauptet, man hätte nicht davor gewarnt...
 
yago said:
Da der controller keinen Cache hat kommt nobarrier ja eher nicht in Frage.
Gibt es sonst noch etwas das ich tun könnte?
Click to expand...

Es gibt viele Möglichkeiten das IO-Subsystem passend zum Workload zu tunen.

Ich würde ersmal testen ob der deadline-Scheduler einen Vorteil gegenüber cfq bringt (oder anders herum).

In deinem Workload (mehrere Threads die große Dateien schreiben) ist aber vermutlich die 'fairness' ein Problem. Wenn Du derzeit CFQ einsetzt würde ich erwarten, dass das Heraufsetzen von /sys/block/<device>/queue/iosched/slice_async sowie .../queue/iosched/slice_async_rq die Performance verbessert. Dann springt nämlich der Scheduler weniger oft von Queue zu Queue und macht größere lineare Schreibzugriffe.



S. z.B.
http://www.linux-magazin.de/Heft-Abo/Ausgaben/2005/04/Kern-Technik2/%28offset%29/4



viel Erfolg,
Nils
 
Ich habe mittlerweile die Ursache finden können.
Der H200 raid controller deaktiviert standardmäßig den Cache der Festplatten, und hat selber auch keinen Cache, daher die schlechte Performance.
Ich habe den cache jetzt aktiviert, und IO Last ist schonmal gesunken.

Mein Hoster hat mir außerdem angeboten, die beiden Festplatten kostenlos gegen zwei 240GB SSDs zu tauschen, ich denke ich werde das Angebot wahrnehmen.
 
Du solltest bei den Partitionen ebenfalls noatime mounten.
Grund ist dass fast alle Linux-Distro aus einem unerklärlichen Grund davon ausgehen dass jeder interessiert ist wann eine Datei zuletzt verwendet wurde.
Das verursacht aber nur massiv Schreiboperationen (eine je geöffnetem Descriptor!) ohne wirklichen Nutzen in 99% der Fälle.

Falls du etwas riskanter leben willst, ebenfalls data=writeback setzen
data=writeback. This means that metadata for files can be written lazily after the file is written. This will not cause file system corruption, but it may cause the most recent changes to be lost in the event of a crash (so you may jump back into the past a bit).
Click to expand...

Dadurch sollte die Performance sehr signifikant hochgehen wenn du viele Festplattenoperationen hast
 
You must log in or register to reply here.
Back
Top