Re: Linux scheduler

Autor: Werner Holtfreter <Holtfreter_at_gmx.de>
Datum: Tue, 11 Oct 2011 22:59:42 +0200
Hallo Markus,

am Montag, 10.10.2011 21:35:55 schrieben Sie:

> Am 10.10.2011 um 16:43 Uhr schrieb Werner Holtfreter

> > Auch meine Versuche mit ionice (auch kombiniert mit nice)
> > zeigen keine merkliche Verbesserung, bei allen drei Varianten
> > entsteht
> > 
> > ähnliche Verlangsamung:
> >   sudo cp -al /home backup.104
> >   sudo ionice -c 3 cp -al /home backup.105
> 
> das verwundert mich. Meine Tests mit ionice waren eher zu gut.
> Wenn ich ionice verwende, dann dauern meine Backup-Jobs
> erheblich länger, allerdings kann ich nicht sagen welche
> Auswirkungen das auf einen Desktop hat, da ich das nur auf
> Servern mache.

Ich habe weiter getestet, diesmal auf der Text-Konsole, um besser 
mess- und reproduzierbare Ergebnisse zu bekommen.

Ein Verzeichnis wird mit cp -a kopiert, das dauert    2' 49".

Läuft gleichzeitig ein weiteres cp -a, dauert es      5' 34",
das ist etwa Verdoppelung und damit plausibel.

Läuft gleichzeitig ein cp -al, dauert es              9' 30",
die Hard-Verlinkung saugt überproportional Ressourcen!

Läuft gleichzeitig ein nice² cp -a, dauert es         2' 56",
so stellt man sich das vor, keine Beeinträchtigung
des normal priorisierten Kopiervorgangs.

Läuft gleichzeitig ein nice² cp -al, dauert es        3' 40",
nice² zeigt Wirkung, dennoch wird der normal
priorisierte Prozess deutlich verzögert.
_________
nice² bedeutet: nice -n 19 ionice -c 3


So ähnlich wie hier gemessen, fühlt sich die Verlangsamung auch auf 
dem Desktop an.

Bei Hardlinks wird ionice den Erwartungen nicht gerecht, die "man 
ionice" weckt:

| Idle   A program running with idle io priority will only get disk
|        time when no other program has asked for disk io for a
|        defined grace period. The impact of idle io processes on
|        normal system activity should be zero.

Über die Ursache kann ich nur spekulieren: Insbesondere beim hier 
verwendeten ReiserFS ist die Erstellung von Hardlinks "nur" eine 
Datenbankoperation. Vermutlich ist es gar nicht möglich, bis 
hinunter auf die Dateisystemverwaltung zu priorisieren, weil das 
Dateisystem ja insgesamt konsistent gehalten werden muss. 
Anscheinend kann cp -al in den zugeteilten kleinen Zeitschlitzen 
doch ein großes Auftragsvolumen an das Dateisystem senden.

Messunsicherheit könnte der im Verhältnis zum kopierten Datenvolumen 
recht große RAM bedeuten. Ich habe immer die gleichen Dateien 
kopiert und so könnte sich der Kernel lesender Weise auch aus dem 
RAM bedient haben. Ich hoffe aber, dass sich das auf die 
Teilversuche gleichmäßig auswirkt.
-- 
Viele Grüße
Werner Holtfreter
-- 
UUGRN e.V. http://www.uugrn.org/
http://mailman.uugrn.org/mailman/listinfo/uugrn
Wiki: https://wiki.uugrn.org/UUGRN:Mailingliste
Archiv: http://lists.uugrn.org/
Empfangen am 11.10.2011

Dieses Archiv wurde generiert von hypermail 2.2.0 : 11.10.2011 CEST