[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Linux scheduler
[Thread Prev] | [Thread Next]
[Date Prev] | [Date Next]
- Subject: Re: Linux scheduler
- From: Werner Holtfreter <Holtfreter@xxxxxx>
- Date: Tue, 11 Oct 2011 22:59:42 +0200
- To: uugrn@xxxxxxxxxxxxxxx
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/