Seite 1 von 1

Prioritäten beim kopieren von Dateien

BeitragVerfasst: 16.06.2009, 15:39
von Nexon
Halllo,

Ich habe bei mir im PC eine 500er Festplatte wo alles drauf ist (OS und Daten) und immer wenn ich z.B. auf oder von einer externen Festplatte etwas verschiebe, aber auch innerhalb der Platte, wird mein System unerträglich langsam, Firefox braucht z.B. 30 Sekunden zum starten und Compiz stellt die Effekte auch nur sehr verzögert dar...

Kann man vllt. die Priorität vom kopieren dahingehend verändern, dass es sich den anderen Applikationen unterordnet?

MfG

BeitragVerfasst: 17.06.2009, 09:16
von Dexter
Du könntest zB die Priorität(der Nice-Wert) des Prozesses verändern, bevor du Daten kopierst.


D3xter

BeitragVerfasst: 17.06.2009, 14:17
von datkev
Das kommt mir recht ungewöhnlich vor das dein System so träge wird beim kopieren von Dateien.

Kannst ja mal gucken was hier für Werte kommen:
hdparm -tT /dev/sda ( mit deinem Festplatten Device ( hda, sdb etc.. ) tauschen )

Wie groß sind die Dateien? Oder sind es eher viele einzelne Dateien?

Musste bisher beim CP nie was am NICE Wert ändern.

BeitragVerfasst: 17.06.2009, 20:59
von Nexon
Bei einzelnen großen Dateien trat das Problem bisher auf, so ab ein paar hundert MB immer, und dann halt sehr krass, so dass man wirklich kaum mehr was machen kann...

Die Konsole spuckt zu deinem Befehl folgendes aus:

Code: Alles auswählen
Timing cached reads:   5226 MB in  2.00 seconds = 2614.55 MB/sec
Timing buffered disk reads:  188 MB in  3.00 seconds =  62.58 MB/sec

BeitragVerfasst: 17.06.2009, 22:26
von Timberland
Ich kann dieses Problem bei mir auch bestätigen.
Nutze Ubuntu 9.04. Es ist auch relativ egal ob ich intern kopiere oder auf externe Speichermedien.

BeitragVerfasst: 17.06.2009, 22:32
von tabtab
Kann ich genauso bestätigen (ich nutz allerdings KDE 4.3 (Beta2) unter ubuntu 9.04
Aber es ist kein Ubuntu(only)problem, unter Mandriva hatte ich das auch. Vielleicht wär es trotzdem gut einen Bugreport zu erstellen, wenns noch keinen gibt :)

BeitragVerfasst: 17.06.2009, 22:37
von Nexon
Hm naja glaube nicht dass das was bringt, ein derartig offensichtliches Problem müsste doch bekannt sein, oder?

BeitragVerfasst: 18.06.2009, 00:07
von phobeus
Das ist der häufigste Irrglaube... das sich schon wer anders drum gekümmert hat. Lässt sich das Problem reproduzieren... insbesondere wenn es zuvor nicht da war, sollte es ruhig gemeldet werden. Wer weiß, was für ein Fehler im Chip dafür verantwortlich sein könnte. Normalweise sollte das System durch ein Kopie nicht unbedingt in die Knie gehen. Sagt "dmesg" parallel etwas aus?

BeitragVerfasst: 18.06.2009, 06:36
von Zappo
Zum Vorschlag "verwende doch nice zum Kopieren" möchte ich anmerken, dass das nicht viel bringen wird, da nice nur den CPU-Scheduler beeinflusst, den IO-Scheduler aber nicht verändert, sodass der Effekt nahe 0 liegen sollte (kopieren ist in den meisten Fällen nicht CPU-lastig). Allerdings gibt es für die Änderungen der Prioritäten am IO-Scheduler ebenfalls ein Programm, welches (ziemlich logisch) ionice heißt. Das sollte dann in etwa
Code: Alles auswählen
ionice -c3 cp ...
oder
Code: Alles auswählen
ionice -c3 -p<PID_von_cp>
heißen, wobei der letztere Fall die Priorität eines bereits laufenden Prozesses ändert.

BeitragVerfasst: 18.06.2009, 14:25
von diri
Ich gehe mal davon aus, das auch die Veränderung des IO-Schedulers keine bzw. kaum eine Änderung bringt. Denn beim Kopieren und Laden, d. h. konkurrierende Zugriffe auf der gleichen Festplatte wirds einfach langsamer. Du wirst sicher auch merken, dass die Köpfe Deiner Platte ziemlich am rödeln sind. Auch beim Kopieren von oder zu einem externen Laufwerk ergibt sich die gleiche Wirkung. Ebenfalls von Bedeutung ist, ob Dein Festplattencontroler NCQ ([url=http://de.wikipedia.org/wiki/Native_Command_Queuing]Native Command Queuing[/url]) unterstützt...
D. h. das es kaum eine andere Lösung gibt als schnellere Festplatten und/oder einen anderen DiskControler. Hier mal die Daten einer schnellen SAS-Disk an einem Controler von LSI:

hdparm -tT /dev/sda

/dev/sda:
Timing cached reads: 11822 MB in 2.00 seconds = 5918.61 MB/sec
Timing buffered disk reads: 354 MB in 3.01 seconds = 117.44 MB/sec
Das vermindert die Wartezeiten doch erheblich...


DiRi

BeitragVerfasst: 18.06.2009, 16:07
von Timberland
Die Probleme treten bei mir unter Windows allerdings nicht auf, somit wird es wohl weniger an der Hardware liegen.

BeitragVerfasst: 18.06.2009, 19:06
von Zappo
[quote=diri,index.php?page=Thread&postID=37041#post37041]Ich gehe mal davon aus, das auch die Veränderung des IO-Schedulers keine bzw. kaum eine Änderung bringt. Denn beim Kopieren und Laden, d. h. konkurrierende Zugriffe auf der gleichen Festplatte wirds einfach langsamer.[/quote]
Genau das ist aber der Sinn von ionice. Es werden die Prioritäten der Lese- und Schreibzugriffe von z.B. cp herabgesetzt und die Lesezugriffe zum Start von Firefox (oder anderen "wichtigen" Programmen) angehoben. Es wird also die Queue verändert, die die Abarbeitung der Zugriffe steuert und das hat einen merklichen Einfluss auf das Verhalten der Anwendungen.

BeitragVerfasst: 18.06.2009, 23:02
von Nexon
Gut, gut und wie genau richte ich das jetzt ein=

BeitragVerfasst: 06.08.2009, 17:07
von Nexon
So folgendes: Bekanntermaßen habe ich ja kein Internet, deswegen würde ich einen Ubuntu-Nutzer hier aus dem Forum bitten, diesen meiner Meinung nach Bug zu melden, damit er in 9.10 behoben wird. Sowas sollte nicht sein, gerade in einer Distri die einen So einsteigerfreundlichen Ruf hat wie Ubuntu.

VIelen Dank demjenigen!