Re: Linux scheduler

Autor: Werner Holtfreter <Holtfreter_at_gmx.de>
Datum: Sun, 10 Jun 2012 19:15:41 +0200
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
> > > 
> > > ä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


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 zäh 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 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 10.06.2012

Dieses Archiv wurde generiert von hypermail 2.2.0 : 10.06.2012 CEST