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/