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
:
Hier ist die Ausgabe iostat -c -z -t -x -d 1
wä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, btrfs
dass 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.
- https://bbs.archlinux.org/viewtopic.php?id=112846&p=1
- http://lwn.net/Articles/467328/
- http://forum.manjaro.org/index.php?topic=2062.0
- Langsame Leistung beim Kopieren von Dateien auf und von USB-Geräten
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.