[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Linux scheduler


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
> > 
> > aehnliche 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 laenger, 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".

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

Laeuft gleichzeitig ein cp -al, dauert es              9' 30",
die Hard-Verlinkung saugt ueberproportional Ressourcen!

Laeuft gleichzeitig ein nice² cp -a, dauert es         2' 56",
so stellt man sich das vor, keine Beeintraechtigung
des normal priorisierten Kopiervorgangs.

Laeuft gleichzeitig ein nice² cp -al, dauert es        3' 40",
nice² zeigt Wirkung, dennoch wird der normal
priorisierte Prozess deutlich verzoegert.
_________
nice² bedeutet: nice -n 19 ionice -c 3


So aehnlich wie hier gemessen, fuehlt 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.

Ueber die Ursache kann ich nur spekulieren: Insbesondere beim hier 
verwendeten ReiserFS ist die Erstellung von Hardlinks "nur" eine 
Datenbankoperation. Vermutlich ist es gar nicht moeglich, 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 grosses Auftragsvolumen an das Dateisystem senden.

Messunsicherheit koennte der im Verhaeltnis zum kopierten Datenvolumen 
recht grosse RAM bedeuten. Ich habe immer die gleichen Dateien 
kopiert und so koennte sich der Kernel lesender Weise auch aus dem 
RAM bedient haben. Ich hoffe aber, dass sich das auf die 
Teilversuche gleichmaessig auswirkt.
-- 
Viele Gruesse
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/