OS 13.1/13.2: Kopieren großer Dateien erzeugt sehr hohe CPU Last (Bug? Weitere Tester gesucht)
Hallo Liste, mir ist Folgendes aufgefallen, und ich würde mich freuen wenn das auch noch jemand testen kann bevor ich einen Bugreport aufmache. Problem: Kopieren großer Dateien führt zu (zu) hoher CPU Last Positiv getestet mit: Opensuse 13.1 (32 und 64 Bit) / 13.2 (64 Bit) Negativ getestet mit: OS 11.4 evergreen (32 Bit) Symptom: Kopieren größerer Dateien (ca. 4 – 10 GByte, z.B. 2 ISO DVD Images) führen während des Kopiervorgangs nach sehr kurzer Zeit zu 80-90 CPU Last. Parallel bricht auch die Datenübertragungsrate sehr stark ein. Laut „top“ geht das primär zu 70 – 80 % auf cpu wait zurück, und nur bis ca. 10 % ist cpu use. Die cpu wait Rate ist m.E. viel zu hoch! Dies tritt beim Kopieren mit dolphin, Konquerer aber auch im Terminal mit „cp“ auf. Ein Abbrechen des Kopiervorganges führt noch ca. weitere 1-2 Minuten zu 70 - 80% cpu wait. Bei mir treten nach solchen Vorgängen sporadisch auch UDMA CRC Fehler auf, muss aber nicht direkt damit zusammen hängen. Der Effekt ist vorhanden bei - Festplatte zu USB-Stick - aber auch Festplatte zu zweiter Festplatte (hier S-ATA zu P-ATA)! - USB Stick zu zweitem USB Stick bremst spürbar das Reaktionsverhalten des Systems aus. Mit OS "11.4 evergreen" passt es noch: es sind alle Werte mindestens halbiert, der „Nachlauf“ bei Abbruch nicht spürbar. Ist hier bereits einmal gemeldet worden: https://bugzilla.novell.com/show_bug.cgi?id=860767 aber ohne dass ich sicher entnehmen kann dass es gefixt wurde. Dort stehen auch Details. Frage: Kann jemand das mal bei sich testen ob das auch auftritt? Oder kennt das Problem bereits jemand? --> Es genügt ca 4 – 10 GByte zu Kopieren, bspw. ISO Images. Parallel dazu top laufen lassen und in der Zeile cpu speziell auf wait % achten. Danke! Wenn es nicht nur bei mir so ist würde ich einen neuen Bugreport aufmachen. Der Fehler macht zwar anscheinend keine Daten kaputt ist aber eine sehr unschöne Regression im Sinne Performance. Grüße, Alexander -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 09.01.2015 um 17:57 schrieb Alexander Thuermer:
.. Problem: Kopieren großer Dateien führt zu (zu) hoher CPU Last
ist mir nicht aufgefallen (Suse 13.2 64bit, 4Kern AMD)
Ein Abbrechen des Kopiervorganges führt noch ca. weitere 1-2 Minuten zu 70 - 80% cpu wait.
Nachlauf schon, (ohne auffällige CPU-Last) ich schiebe das auf die Cache-Fähigkeiten von Linux. Die Daten werden auch in den Hauptspeicher kopiert, sofern dort Platz ist und von dort auf die Platte geschrieben. Merkbar seit hier 16GB auf dem Mainboard sind, gegenüber vorher 4GB. Hast du die Platte schon einmal mit smartctl untersucht?. Ein GUI dafür ist gsmartcontrol. Gruß Peter -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Fri, 09 Jan 2015 17:57:59 +0100 schrieb Alexander Thuermer <alex.oslist@arcor.de>:
Ein Abbrechen des Kopiervorganges führt noch ca. weitere 1-2 Minuten zu 70 - 80% cpu wait.
Bei mir treten nach solchen Vorgängen sporadisch auch UDMA CRC Fehler auf, muss aber nicht direkt damit zusammen hängen.
Der Effekt ist vorhanden bei - Festplatte zu USB-Stick - aber auch Festplatte zu zweiter Festplatte (hier S-ATA zu P-ATA)! - USB Stick zu zweitem USB Stick bremst spürbar das Reaktionsverhalten des Systems aus.
Die CRC-Fehler weisen m.E. am ehesten in die richtige Richtung. Offenbar hat der Kernel Probleme beim Massenspeicherzugriff, was am ehesten irgendwo zwischen Memory und Massenspeicher-IO seine Ursache hat - Treiber/Kernel-Module inklusive. Den "Nachlauf" würde ich darauf zurückführen, dass im Hintergrund aus dem write-behind cache auf den Massenspeicher weitergeschrieben wird. Performance-Probleme beim IO sieht man recht gut in "top", wenn man mit "i" die verzögerten Prozesse ansieht. Normalerweise sieht man kaum Prozesse mit running-state (S) "D", bei Überlast schon. Abgesehen von schleichenden Festplattendefekten (bei USB-Sticks unwahrscheinlich... ;) ) taucht das bei mir hauptsächlich bei defekten Hostadaptern, ihren Verbindungen oder bei Übertemperaturen einzelner Komponenten auf. Das kann die Festplatte sein, aber auch eine schlecht montierte CPU heizt mitunter schnell auf und drosselt sich dann selbst. Also neben allgemeiner Beobachtung des Kernel-Log auch die Temperaturmonitore aktivieren (SMART für Festplatte, lm_sensors für Mainboard und CPU). Ich habe hier zum Beispiel ein System, bei dem zwei am IDE-Hostadapter angeschlossenen Platten eine zunehmende Zahl von CRC-Fehlern liefern, wenn sie zu heiß werden. Irgendwann werden sie dann ganz abgeklemmt, aber bis dahin stockt das System immer mehr durch retries. Den Grund in einer neueren Kernel-Version zu suchen, würde ich zunächst vermeiden, weil man da schnell im Wald landet. Tatsächlich sind von einer OS-Version zur nächsten viele Parameter geändert. Neue Applikationen, neue Konzepte oder ganz schlicht höhere Last durch zusätzliche Standardprozesse machen Fehlereingrenzung via Vergleich zu komplex. Oder die Hardware hatte vorher schon eine Macke, die nur zufällig nicht zum Tragen kam. Du solltest das auch mal mit genaueren Daten unterfüttern. Welche Datentransferraten erreicht das System bei welchen Kopiervorgängen? Welches USB-device, welche USB-Version? Welche Hardware? Bremst es auch beim Nur-Lesen oder Nur-Schreiben (Test mit dd von /dev/zero oder dd nach /dev/null !) auf die verschiedenen devices. Gruß, Tobias. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Tobias Crefeld schrieb am 09.01.2015 um 19:23:
Am Fri, 09 Jan 2015 17:57:59 +0100 schrieb Alexander Thuermer <alex.oslist@arcor.de>:
Ein Abbrechen des Kopiervorganges führt noch ca. weitere 1-2 Minuten zu 70 - 80% cpu wait.
Bei mir treten nach solchen Vorgängen sporadisch auch UDMA CRC Fehler auf, muss aber nicht direkt damit zusammen hängen.
Der Effekt ist vorhanden bei - Festplatte zu USB-Stick - aber auch Festplatte zu zweiter Festplatte (hier S-ATA zu P-ATA)! - USB Stick zu zweitem USB Stick bremst spürbar das Reaktionsverhalten des Systems aus. Die CRC-Fehler weisen m.E. am ehesten in die richtige Richtung. Offenbar hat der Kernel Probleme beim Massenspeicherzugriff, was am ehesten irgendwo zwischen Memory und Massenspeicher-IO seine Ursache hat - Treiber/Kernel-Module inklusive. Ja nehme ich auch an - nur keine Idee Den "Nachlauf" würde ich darauf zurückführen, dass im Hintergrund aus dem write-behind cache auf den Massenspeicher weitergeschrieben wird. Wahrscheinlich ja - da die Schreibrate parallel ja gering wird, dauert das "Flushen" natürlich auch länger Performance-Probleme beim IO sieht man recht gut in "top", wenn man mit "i" die verzögerten Prozesse ansieht. Normalerweise sieht man kaum Prozesse mit running-state (S) "D", bei Überlast schon. mit "i" zeigt plasma-desktop, kio_file,kworker /u8:1, kworker /0:2,konsole Abgesehen von schleichenden Festplattendefekten (bei USB-Sticks unwahrscheinlich... ;) ) taucht das bei mir hauptsächlich bei defekten Hostadaptern, ihren Verbindungen oder bei Übertemperaturen einzelner Komponenten auf. Das kann die Festplatte sein, aber auch eine schlecht montierte CPU heizt mitunter schnell auf und drosselt sich dann selbst. [...] Hardware kann ausgeschlossen werden; da selbes Szenario nochmal unter Opensuse 11.4 (evergreen, die war bis vor 2 Monaten meine Arbeitsversion) getestet und alles im erwarteten Bereich. Gerade nochmal getestet.
P.S: Platten sind via smartctl inkl. selftest beide ok
Den Grund in einer neueren Kernel-Version zu suchen, würde ich zunächst vermeiden, weil man da schnell im Wald landet. Tatsächlich sind von einer OS-Version zur nächsten viele Parameter geändert. Neue Applikationen, neue Konzepte oder ganz schlicht höhere Last durch zusätzliche Standardprozesse machen Fehlereingrenzung via Vergleich zu komplex. Oder die Hardware hatte vorher schon eine Macke, die nur zufällig nicht zum Tragen kam. Kernel oder Module habe ich im Verdacht, aber stehe wie Du sagtest eher im Wald; eventuell hat sich für eine spezifische Komponente bei mir der Kernel-Treiber geändert oder so etwas. Specs s.u. Du solltest das auch mal mit genaueren Daten unterfüttern. Welche Datentransferraten erreicht das System bei welchen Kopiervorgängen? Welches USB-device, welche USB-Version? Welche Hardware? Bremst es auch beim Nur-Lesen oder Nur-Schreiben (Test mit dd von /dev/zero oder dd nach /dev/null !) auf die verschiedenen devices.
Gruß, Tobias. Intel Core2 Duo 3GHz, 8 GB RAM, WD Enterprise 2TByte, WD Caviar 320 GByte MSI P6N SLI mit nForce 650i d.h. USB 2.0 Sticks: Transcend 32 GB u.a. alle USB 2.0
Schreibraten kopieren in Dolphin bei Disk2Disk: 11.4 konstant ~50 MB/s 13.1 erst 118 MB/s dann nach 30Sek ca. 18 MB/s Wie gesagt HW Defekt scheidet aus da es unter OS 11.4 geht. Falls der Fehler bei niemandem anderen auftritt ist es dann eher die HW Config von mir und ich untersuche und google hier selbst weiter. Falls das jedoch bei einem Test auch bei anderen auftritt, dann ist das ein Problem in der Distri (es gab ja schon mal von jemanden einen bugreport). Dann würde ich einen Bugreport aufmachen. Deshalb hier nachgefragt vielen Dank Alexander -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
nur ergänzend: die UDMA CRC Fehler traten nur bei großen langen Aktionen auf z.B. ganze Partitionen sichern. Im "normalen" Betrieb niw. Hab das mit smartctl beobachtet. Sie treten auch nur auf der 2TByte WD auf. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Allen nochmals vielen Dank - hat sich weitgehend geklärt: 1) der hohe IO-wait ist wohl normal da die neueren Kernel,speziell der Desktop Kernel von OS 13.1 erst einmal sehr intensiv den RAM Cache füllen und dann die Festplatte nicht hinterherkommt. -> habe den "default" Kernel installiert, da ist das Caching gemäßigter und ähnlich Opensuse 11.4 2) Die UDMA CRC Fehler [2], die ich unter dem selbem Test in 13.1 bekomme und zuverlässig NICHT unter 11.4 evergreen geht wohl auf Probleme mit neueren Kernel Versionen mind. ab 3.11 und den Treibern für ÄLTERE SATA Controllern zurück. Da scheint es einen noch ungefundenen Bug zu geben, der bei starkem Lesen oder Schreiben mit NCQ aktiviert bei SATA Controllern im "IDE Modus" (nicht AHCI) UDMA Fehler produziert [2]. Opensuse 11.4 evergreen mit älterem Kernel 3.0 ist davon wohl nicht betroffen und daher kann ich das dort auch nicht reproduzieren (mit NCQ aktiviert). Abhilfe schafft bei manchen Konstellationen NCQ per echo 1 > /sys/block/sdb/device/queue_depth zu deaktivieren. Hat zumindestens heute bisher beim Testen keine UDMA CRC errors geworfen. Werde das genauer beobachten und schauen ob es schon einen Bugreport bei Opensuse gibt. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1084928 https://bugzilla.kernel.org/show_bug.cgi?id=89261 http://www.itechlounge.net/2013/07/linux-ata-failed-command-read-fpdma-queue... [2] Fehler Meldungen bei mir: 2015-01-11T21:19:36.238411+01:00 linux-os131b64 kernel: [14936.666817] ata3.00: failed command: WRITE FPDMA QUEUED 2015-01-11T21:19:36.238411+01:00 linux-os131b64 kernel: [14936.666821] ata3.00: cmd 61/00:90:00:7c:78/04:00:2b:00:00/40 tag 18 ncq 524288 out 2015-01-11T21:19:36.238412+01:00 linux-os131b64 kernel: [14936.666821] res 41/84:60:80:f6:77/84:00:2b:00:00/40 Emask 0x10 (ATA bus error) 2015-01-11T21:19:36.238413+01:00 linux-os131b64 kernel: [14936.666822] ata3.00: status: { DRDY ERR } 2015-01-11T21:19:36.238414+01:00 linux-os131b64 kernel: [14936.666824] ata3.00: error: { ICRC ABRT } -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Alexander Thuermer schrieb:
Hallo Liste,
mir ist Folgendes aufgefallen, und ich würde mich freuen wenn das auch noch jemand testen kann bevor ich einen Bugreport aufmache.
Problem: Kopieren großer Dateien führt zu (zu) hoher CPU Last
Positiv getestet mit: Opensuse 13.1 (32 und 64 Bit) / 13.2 (64 Bit) Negativ getestet mit: OS 11.4 evergreen (32 Bit)
Um die Sache mal einzugrenzen: ich hab mal den Test gemacht OS 13.1-32 - 4 GB mit 5 HDs (Dateisysteme ext4, xfs, ntfs über usb) a) eine 4,7GB-Iso über smb von Win-Client auf internes ext4-LW konstante CPU-Last - Einbrüche gab es nur kurz wenn der Client nicht liefern konnte) b) auf os-Rechner von ext4-HD auf xfs-Laufwerk mit mc konstante CPU-last c) von ext4-HD auf USB-Platte per usb2 konstante CPU-Last. alles normal .. Auch das könnte auf ein Hardware-Problem hinweisen -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Lutz Nülle schrieb am 09.01.2015 um 20:03:
Alexander Thuermer schrieb:
Hallo Liste,
mir ist Folgendes aufgefallen, und ich würde mich freuen wenn das auch noch jemand testen kann bevor ich einen Bugreport aufmache.
Problem: Kopieren großer Dateien führt zu (zu) hoher CPU Last
Positiv getestet mit: Opensuse 13.1 (32 und 64 Bit) / 13.2 (64 Bit) Negativ getestet mit: OS 11.4 evergreen (32 Bit)
Um die Sache mal einzugrenzen: ich hab mal den Test gemacht
OS 13.1-32 - 4 GB mit 5 HDs (Dateisysteme ext4, xfs, ntfs über usb)
a) eine 4,7GB-Iso über smb von Win-Client auf internes ext4-LW konstante CPU-Last - Einbrüche gab es nur kurz wenn der Client nicht liefern konnte) b) auf os-Rechner von ext4-HD auf xfs-Laufwerk mit mc konstante CPU-last c) von ext4-HD auf USB-Platte per usb2 konstante CPU-Last.
alles normal ..
Auch das könnte auf ein Hardware-Problem hinweisen
Danke erstmal! HW scheidet aus da auf der parallel installierten OS 11.4 alles passt. Gerade nochmal getestet. konstante CPU hab ich auch ggf nicht ganz klar heraus gekommen - wie hoch ist den deine "konstante CPU" - eher 80 -95% (mein Wert 13.1 / 13.2) oder 40-50% (OS 11.4)? -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Alexander Thuermer schrieb:
Lutz Nülle schrieb am 09.01.2015 um 20:03:
Alexander Thuermer schrieb:
Hallo Liste,
mir ist Folgendes aufgefallen, und ich würde mich freuen wenn das auch noch jemand testen kann bevor ich einen Bugreport aufmache.
Problem: Kopieren großer Dateien führt zu (zu) hoher CPU Last
Positiv getestet mit: Opensuse 13.1 (32 und 64 Bit) / 13.2 (64 Bit) Negativ getestet mit: OS 11.4 evergreen (32 Bit)
Um die Sache mal einzugrenzen: ich hab mal den Test gemacht
OS 13.1-32 - 4 GB mit 5 HDs (Dateisysteme ext4, xfs, ntfs über usb)
a) eine 4,7GB-Iso über smb von Win-Client auf internes ext4-LW konstante CPU-Last - Einbrüche gab es nur kurz wenn der Client nicht liefern konnte) b) auf os-Rechner von ext4-HD auf xfs-Laufwerk mit mc konstante CPU-last c) von ext4-HD auf USB-Platte per usb2 konstante CPU-Last.
alles normal ..
Auch das könnte auf ein Hardware-Problem hinweisen
Danke erstmal!
HW scheidet aus da auf der parallel installierten OS 11.4 alles passt. Gerade nochmal getestet.
konstante CPU hab ich auch ggf nicht ganz klar heraus gekommen - wie hoch ist den deine "konstante CPU" - eher 80 -95% (mein Wert 13.1 / 13.2) oder 40-50% (OS 11.4)?
bei a) 30- 40 % (bei Client-Lieferproblemen runter auf 2 %) bei b) 70-80 % konstant - war aber auch sekundenschnell fertig bei c) konstant 60% - aber das war langsam wg. usb-1 -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
participants (4)
-
Alexander Thuermer -
Lutz Nülle -
Peter Mc Donough -
Tobias Crefeld