Hohe Last durch flush:8-0. Was ist das ?

[Eisenbart]

Hallo,

ich habe hier das Problem das beim kopieren von größeren Datenmengen (DVD Image) ein Prozess nahmens flush:8-0 Stoßweise hohe IO auf die Platte bringt. Gleichzeitig werden alle laufenden Berechnungen von Running auf Disksleep gesetzt. Das System ist Ubuntu 10.04 / Ext 4 - Standartinstall halt.
Kann jemand sagen was das für ein Prozess ist, was er tut. Und wie man ihn los wird.

gruß

 

[DjNDB]

Möglicherweise wird da der Schreibcache (RAM) mit dem Datenträger synchronisiert?

 

[Eisenbart]

Hmm, das könnte sein. Aber warum ist das so ungünstig gestaltet ? Der ganze Rechner geht dabei in die Knie. Das schreiben ist ja auch eher Burstweise. Außerdem wurde ja mit nur 40mbs kopiert. Das sollte die Platte doch locker schaffen.

 

[Sannyboy111985]

Dem würd ich zustimmen. Der Prozess flush entleert normalerweise den Buffercahce von Linux auf die Platten. Lässt sich auch von Hand durch das SYNC Kommando auslösen.
Auf was für einen System läuft das ganze denn (HW) und aus welchen Programm ziehst du die Infos?

 

[DjNDB]

Es gibt dazu auch eine Aussage von dem Ubuntu Entwickler Andy Whitcroft:

(11:11:07 AM) ClassBot: bullgard4 asked: '~$ ps -ef | grep flush; root 252 2 0 May05 ? 00:00:00 [flush-8:0]' What process spawns this process? Where is described the function of this process?
(11:11:58 AM) apw: those processes are spawed by the kernel itself to handle flushing of block devices within the kernel, they are there to provide process
(11:12:35 AM) apw: contexts where needed. they are tripped by fsync and similar calls to perform data-writes. they are relativly new and may not appear before kucid
(11:12:37 AM) apw: lucid

 

[Eisenbart]

Ubuntu 10.04 / 32GB RAM - ECC Registered / 2X Quad-Core AMD Opteron(tm) Processor 2389 / WD Enterprise Storage 500 GB Platte

Es ist egal ob die Daten über Infinband oder LAN reinkommen. Ab einer bestimmten Datenmenge tritt dieser Effekt auf.

Ermittelt mit iotop und htop.

Ergänzung (4. August 2010)

Es gibt dazu auch eine Aussage von dem Ubuntu Entwickler Andy Whitcroft:

Das ist ja mal spannend. Da ich aber große Datenmenge bewegen muss, verabschieden sich immer die Berechnungen für eine geweisse Zeit. Scheibar scheint das ja jetzt in allen neuen Kernelnsen (wie ist denn da bloß der Plural ?) drin zu sein.

Kann man das irgendwie steuern ? Dieses Burstwriting scheint irgendwie das Problem zu sein. Oder liegt das am ext4 Dateisystem unter Linux ?

Das Problem ist ja, das für Minuten alle Prozesse down sind und man nichts machen kann. Gleichzeitiog kommt der I/O auf die Festplatte nur sehr selten von flush. Festpaltte ist auch in Ordnung. Wenn ich mit scp oder wget ein Image auf die Platte kopiere zeigt mit iotop auch an, das geschrieben wird. Es werden auch nicht die 4GB gecached. Wir ist daher nicht klar was dieser Prozess tut.

 

[DjNDB]

Kann man das irgendwie steuern ? Dieses Burstwriting scheint irgendwie das Problem zu sein. Oder liegt das am ext4 Dateisystem unter Linux ?

Es gibt /proc/sys/vm/bdflush, aber ich bin nicht sicher ob es das selbe ist.
Es kann auch irgendein bug sein der nichts mit den Einstellungen zu tun hat. Man könnte das ganze ja mal in einer VM nachstellen.

 

[Eisenbart]

Unter Ubuntu scheint das /proc/sys/vm/ anders aufgebaut zu sein. Die erwähnte Datei exixtiert nicht, aber Datein die nach den Parametern im Link klingen. Habe bloß keinen Plan an welchem das leigen könnte, wenn das denn das Problem ist... .

Hier mal die dmesg ausgabe dazu:
http://pastebin.com/jMPa95sthttp://pastebin.com/jMPa95st

Es hängen sogar Przesse wie apg-get auf disksleep...

 

[DjNDB]

Kannst du vielleicht mal die SMART Werte der Platte posten? Vielleicht ist ja schon hardwareseitig etwas defekt.

 

[Eisenbart]

Danke das du am Thema bleibst. Die Platte habe ich gestern neu eingebaut. Und es tritt auf zwei identischen Rechner auf. Von daher würde ich das mal ausschließen. Aber hier sind die Werte:

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x002f 100 253 051 Pre-fail Always - 0
3 Spin_Up_Time 0x0027 142 142 021 Pre-fail Always - 3875
4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 10
5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0
7 Seek_Error_Rate 0x002e 200 200 000 Old_age Always - 0
9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 54
10 Spin_Retry_Count 0x0032 100 253 000 Old_age Always - 0
11 Calibration_Retry_Count 0x0032 100 253 000 Old_age Always - 0
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 8
192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 7
193 Load_Cycle_Count 0x0032 200 200 000 Old_age Always - 2
194 Temperature_Celsius 0x0022 118 113 000 Old_age Always - 25
196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0
197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0030 200 200 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 0
200 Multi_Zone_Error_Rate 0x0008 200 200 000 Old_age Offline - 0

 

[Sensei21]

das problem ist, dass Ubuntu einen (relativ gesehen) alten Kernel hat, bei dem die Barrier-Schreibperformance noch recht schlecht ist und das System in die Knie zwingt

eine Lösung wäre

die jeweilige Partition mit barrier=0 zu mounten - was ich jedoch aus Datenschutzgründen nicht empfehlen kann

andernfalls noatime,nodiratime zu den Mount-Optionen hinzufügen und mal schauen, ob es so besser wird

 

[Eisenbart]

Das ist doch ein 32er Kernel. Wirklich alt ist das jetzt auch nicht. Das mit dem mounten werde ich mal probieren. Ich verstehe bloß nicht wie das Problem lösen soll, es wurde ja immer nur eine iso kopiert. Weil es gibt ja nicht viel I/O laut iotop. Es sei denn iotop funktioniert auch nicht mehr richtig weil es ausgebremmst wird.

Ich werde das morgen mal probieren und dann berichten ob es daran lag. Und BIOS Settings mal überprüfen. Kann ja sein das da was seltsames steht.

 

[DjNDB]

Ich habe gerade mal meine VM auf Ubuntu 10.04 aktualisiert.
Wenn ich die ubuntu-10.04-desktop-amd64.iso mit cp in das selbe Verzeichnis kopiere, dann braucht flush etwa 5-10% cpu zeit, cpu etwa 10-18%.
Wie ist das bei dir wenn du Daten lokal kopierst?

 

[Eisenbart]

Eigentlich braucht flush nur ganz wenig CPU. Die meiste Zeit fast gar nichts. Jetzt nach einem restart ist das Problem noch immer vorhanden. Obwohl nichts kopiert wurde. Es hängt immer wieder. Scheint so als ob Prozesse hängen weil die auf I/O warten (htop Spalte Status D == Disksleep). Woran das jetzt liegt kann ich nicht sagen. Werde mir das Morgen mal weiter ansehen und dann berichten.

Danke für deine Hilfe bisher.

Ergänzung (4. August 2010)

cat /dev/zero > zero.txt gibt für wenige sekunden das folgende bild:

cat 100% CPU ; flush ca. 15% und jbd2/sda1 ca. 15%

wenige sekunden später war cat dann wieder auf status D und keine CPUlast mehr und die anderen beiden waren nicht mehr zu sehen.

 

[xXNeXoNXx]

Ich kann dir auf jeden Fall sagen, dass unter Ubuntu und auch z.B. Arch das Arbeiten mit sehr großen Datenmengen (>1GB) immer zu Lastspitzen führt, die das ganze System lahmlegen. Das ist so beim Entpacken von Archiven, beim Kopieren, Verschieben etc. Woran genau das liegt weiß ich auch nicht, es ist jedenfalls extremst störend

//EDIT: Und das Problem hatte ich aber bspw. mit "cp" auf der Konsole nicht...

 

[Eisenbart]

Aber auch das Entpacken von Packeten mit dpkg fürht zu Probleme. Das sind ja keine Datenmengen.

 

[Sensei21]

ach so, DAS meinst du !

dieses Performance-Problem wurde mit der letzten RC eingeführt (davor gab es Betas ?) - sorry, ich nutze Ubuntu nicht so häufig, weiß daher nicht so genau, wie es mit den Pre-Releases ausschaut,

jedenfalls haben die das noch nicht behoben, ich hatte es damals schon gemeldet - sieht wohl schlecht aus

dieses Problem macht mich verrückt - wenn dieses nicht wäre, hätte ich schon längst auf Ubuntu migriert ...

 

[Eisenbart]

Da wir jetzt auch Ubuntu im Verdacht hatten, haben wir das letzte Arch-release genommen. Ist das selbe Problem. Daher neue Theorien :
Entweder die Kernel ab 32 haben ein Problem mit genau den neu gekauften Platten oder wir habe 3 defekte Platten gekauft. Also wieder andere Platten Platten besorgen und wieder Probieren. Sag dann wieder Bescheid.

 

[Sensei21]

ncq (für die Platten) deaktivieren, cfq nehmen und diesen etwas "tunen"

versuch einmal Folgendes:

for i in /sys/block/sd*; do
/bin/echo "cfq" > $i/queue/scheduler
# /bin/echo "0" > $i/queue/iosched/slice_idle # default: 6, 0 fixes low throughput with drives which have a buggy ncq implementation
# /bin/echo "4" > $i/queue/iosched/slice_async_rq # default: 2
# /bin/echo "16384" > $i/queue/iosched/back_seek_max # default: 16384
/bin/echo "8" > $i/queue/iosched/quantum # default: 4
/bin/echo "1" > $i/queue/iosched/low_latency # default: 1
/bin/echo "1024" > $i/queue/nr_requests

done

 

[Eisenbart]

Haben jetzt eine Platte von Seagate gekauft und mich Arch Linux bespielt. Diese Verhält sich so wie es sein soll. Große Datenmengen führen nur beim syncen zu ausfällen. Die Western Digital Platten scheinen laut "sudo smartctl -t long /dev/sdb" nicht defekt zu sein. Es sieht alles so aus als währen die neu gekauften "WD5000AAKS-00V1A00 Firmware 05.01.D05" das Problem. Irgendwie verstehen die sich mit neueren Kernelversionen nicht. Ob das nur Speziell für dieses Mainboard gilt kann ich nicht sagen.
Auch die Möglichkeit das die Platten nicht mit dem Mainboard klar kommen und es gar nicht am Kernel liegt besteht.
Danke für deine Hilfe !