Warum stürzt mein Desktop ab, wenn ich viele Dateien auf ein USB-Laufwerk kopiere?

Warum stürzt mein Desktop ab, wenn ich viele Dateien auf ein USB-Laufwerk kopiere?

Mein Desktop reagiert normalerweise sehr schnell, selbst bei hoher Belastung. Aber wenn ich Dateien auf ein USB-Laufwerk kopiere, hängt es sich nach einiger Zeit immer auf. Mit „hängen“ meine ich:

  • Das Verschieben des Fokus von einem Fenster zum anderen kann 10–20 Sekunden dauern
  • Das Wechseln des Desktops kann 10 bis 20 Sekunden dauern
  • Videos werden nicht mehr aktualisiert (bei YouTube wird der Ton weiter abgespielt, nur das Video friert ein)

Die Systemlast ist in diesem Fall nicht außergewöhnlich hoch. Manchmal sehe ich in xosview viel Weiß, was darauf hinweist, dass der Kernel irgendwo beschäftigt ist.

Auf den ersten Blick sieht es so aus, als würde das Kopieren von Dateien auf das USB-Laufwerk Compiz irgendwie beeinträchtigen, aber ich kann mir keinen Zusammenhang vorstellen.

Hier ist die Ausgabe von htop:

Ausgabe von htop kurz nach dem Hängenbleiben

Hier ist die Ausgabe iostat -c -z -t -x -d 1während eines 2-minütigen Hängens:

19.07.2012 20:38:22
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           1,27    0,00    0,38   37,52    0,00   60,84

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sdg               0,00     2,00    0,00  216,00     0,00 109248,00  1011,56   247,75  677,69    0,00  677,69   4,63 100,00

Wie man sieht, ist nur die externe Festplatte aktiv. Hier ist das komplette Log:http://pastebin.com/YNWTAkh4

Der Hänger begann um 20:38:01 und endete um 20:40:19.

Softwareinformationen:

  • openSUSE 12.1
  • KDE 4.7.x
  • Dateisysteme: Reiserfs und Btrfs auf meiner internen Festplatte, Btrfs auf dem USB-Stick

Antwort1

Meine erste Vermutung war, btrfsdass es daran liegt, dass die E/A-Prozesse dieses Dateisystems manchmal die Kontrolle übernehmen. Aber das würde nicht erklären, warum X abstürzt.

Wenn ich mir die Interrupts anschaue, sehe ich Folgendes:

# cat /proc/interrupts 
           CPU0       CPU1       CPU2       CPU3       CPU4       CPU5       CPU6       CPU7       
  0:        179          0          0          0          0          0          0          0  IR-IO-APIC-edge      timer
  1:          6          0          0          0          0          0          0          0  IR-IO-APIC-edge      i8042
  8:          1          0          0          0          0          0          0          0  IR-IO-APIC-edge      rtc0
  9:          0          0          0          0          0          0          0          0  IR-IO-APIC-fasteoi   acpi
 12:         10          0          0          0          0          0          0          0  IR-IO-APIC-edge      i8042
 16:    3306384          0          0          0          0          0          0          0  IR-IO-APIC-fasteoi   ehci_hcd:usb1, nvidia, mei, eth1

Na, klar. Der USB-Treiber verwendet denselben IRQ wie die Grafikkarte und ist der erste in der Kette. Wenn er abstürzt (weil das Dateisystem etwas Kostspieliges tut), verhungert die Grafikkarte (und auch das Netzwerk).

Antwort2

Ich hatte ähnliche Probleme mitopenSUSEIch habe den Linux-3.1-Kernel von 12.1 ausprobiert und festgestellt, dass das Deaktivieren von Transparent Huge Pages hilfreich ist:

echo never > /sys/kernel/mm/transparent_hugepage/enabled

Das zugrunde liegende Problem besteht darin, dass der Kernel, wenn eine Anwendung 4 MB oder mehr zuweist, versucht, ihr eine riesige Seite zuzuweisen, für die er ganze zusammenhängende 4 MB RAM benötigt. Wenn nun viele schmutzige Seiten vorhanden sind, die noch auf ein langsames USB-Gerät geschrieben werden müssen, wartet er, bis dieser IO abgeschlossen ist, bevor er mit der Speicherzuweisung fortfährt.

Antwort3

Wie erwähnt, hat dies wahrscheinlich mit dem Kernel-Hugepages-Setup zu tun. Ich kenne mehrere Leute mit diesem Problem. Im Internet finden Sie verschiedene Dokumentationen dazu, z. B.

Ich habe das Problem in meinem Setup vollständig behoben, indem ich Folgendes getan habe. Beachten Sie, dass Ihre Ergebnisse unterschiedlich ausfallen können. Möglicherweise sind nicht alle der unten aufgeführten Korrekturen erforderlich und möglicherweise reichen sie nicht aus. Ehrlich gesagt habe ich vielleicht etwas vergessen. Wie dem auch sei, das ist mein Setup und es funktioniert.

  • Verwenden Sie den Linux-CK-Kernel
  • echo madvise > /sys/kernel/mm/transparent_hugepage/enabled
  • echo never > /sys/kernel/mm/transparent_hugepage/defrag

Antwort4

Wechseln Sie das Kabel. Entfernen Sie Oxid vom USB-Anschluss/Kabel.

verwandte Informationen