Re: Linux scheduler

[Werner Holtfreter <Holtfreter@xxxxxx>]

Hallo,

ich ziehe mal einen alten Thread ans Licht, daher Vollquote:

Am Dienstag, den 11.10.2011, 22:59 +0200 schrieb Werner Holtfreter:

> 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


Das Problem nervt immer noch. Ich spiegele eine Festplatte mit

  historyint="/dev/disk/by-path/pci-0000:00:09.0-scsi-2:0:0:0"
  historyext="/dev/disk/by-path/pci-0000:00:09.0-scsi-3:0:0:0"

  nice -n 19 ionice -c 3 cp $historyint $historyext

worauf (als Test) ein Zweitstart von LibreOffice Calc mindestens
3 mal so lang dauert und der Rechner auch insgesamt zaeh reagiert.
Calc kommt von der Systemplatte, die nicht identisch mit den
beiden oben genannten Platten ist.

cat /sys/block/sda/queue/scheduler
noop deadline [cfq] 

Jemand eine Idee?
-- 
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/