☰

Wie kann die Berechnung von „tar czf“ über einen längeren Zeitraum verteilt werden?

tag-icon • tag-icon backup tar power-management xargs sleep
Wie kann die Berechnung von „tar czf“ über einen längeren Zeitraum verteilt werden?

Meine Systeme werden stark belastet, wenn ich

sudo tar czf /media/masi/ntfsDisc/backup_home.tar.gz $HOME/

Lüfter laufen auf Maximum usw. Ich würde gerne ein besseres Gleichgewicht zwischen Rechenleistung und Stromverbrauch finden. Ich kann den Prozess nicht gut genug überwachen. Man kann ihn während der Berechnung nicht verlangsamen, wenn er so läuft. Intuition: da etwas Ruhe hinzufügen, aber wie? Ich hätte xargsauch wirklich gerne einen Ansatz, um es mit „fertigen“ Produkten zu vergleichen. Meine Tops

  • Ich tue topin Ruhe

    top - 09:34:34 up 19:14,  1 user,  load average: 0.52, 0.42, 0.24
Tasks: 236 total,   1 running, 235 sleeping,   0 stopped,   0 zombie
%Cpu(s):  1.5 us,  1.1 sy,  0.0 ni, 97.4 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 s
KiB Mem :  8115460 total,   257036 free,  3006452 used,  4851972 buff/cache
KiB Swap:  8326140 total,  8321852 free,     4288 used.  4369448 avail Mem

  • Ich mache top1 Minute nach demnice tar czf ...

    top - 09:48:49 up 19:28,  1 user,  load average: 1.63, 0.99, 0.62
Tasks: 244 total,   2 running, 242 sleeping,   0 stopped,   0 zombie
%Cpu(s):  1.4 us,  0.9 sy, 24.1 ni, 73.2 id,  0.3 wa,  0.0 hi,  0.1 si,  0.0 s
KiB Mem :  8115460 total,   127644 free,  3237648 used,  4750168 buff/cache
KiB Swap:  8326140 total,  8321868 free,     4272 used.  4092404 avail Mem 

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND   
28831 root      30  10    4640   1600   1316 R  97.7  0.0   1:43.24 gzip      
 9573 root      20   0   21196   2860   1772 S   2.3  0.0  13:16.29 mount.nt+ 
  842 root      20   0  380136  63780  48568 S   1.7  0.8  23:57.16 Xorg

  • Ich mache top10 Minuten nach dem Start

    top - 10:00:33 up 19:40,  1 user,  load average: 1.98, 2.13, 1.50
Tasks: 253 total,   2 running, 251 sleeping,   0 stopped,   0 zombie
%Cpu(s):  2.6 us,  2.8 sy, 21.4 ni, 73.0 id,  0.2 wa,  0.0 hi,  0.0 si,  0.0 s
KiB Mem :  8115460 total,   130408 free,  4432384 used,  3552668 buff/cache
KiB Swap:  8326140 total,  8321948 free,     4192 used.  2837616 avail Mem 

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND   
28831 root      30  10    4640   1600   1316 R  87.0  0.0  11:49.08 gzip      
 9573 root      20   0   21196   2860   1772 S  13.6  0.0  14:45.84 mount.nt+ 
  842 root      20   0  384936  66304  51092 S   2.0  0.8  24:18.44 Xorg      
28830 root      30  10   37584   3096   2688 S   1.3  0.0   0:14.50 tar       
 1674

Mein PVtar cf - $HOME/ | pv | gzip > media/masi/ntfsDisc/testbackup.tar.gz

  • bei 1 Minute 13 – 22 MB/s; bei 2 Minuten 14 – 22 MB/s; bei 3 Minuten 5 – 7 MB/s; bei 4 Minuten 5 – 22 MB/s; bei 5 Minuten 15 – 17 MB/s; bei 6 Minuten 8 – 24 MB/s; bei 7 Minuten 16 – 20 MB/s
  • bei 19 min, 18-21 MB/s und Lüfter wenig/dauerhaft an, so dass man sie hören kann

System: Ubuntu 16.04 64 Bit
Hardware: Macbook Air 2013-Mitte

Antwort1

Erstens wird der Gesamtstromverbrauch wahrscheinlich gleich oder höher sein, wenn Sie den Sicherungsvorgang künstlich verlangsamen. Einfach, weil die Gesamtzahl der Vorgänge gleich ist und die CPU weniger Spitzenleistung verbraucht, wenn der Vorgang länger dauert, aber über einen längeren Zeitraum. Wenn der Vorgang beispielsweise 10 s lang bei einer Spitzenleistung von 200 W läuft, verbraucht er 10 s*200 W=2000 J, wenn der Vorgang 100 s lang bei 30 W läuft, verbraucht er 100 s*30 W=3000 J.

Wenn es Ihnen vor allem darum geht, die Reaktionsfähigkeit Ihres Computers während des Prozesses zu verbessern, können Sie versuchen, die Niceness des Prozesses zu erhöhen (Nice senkt die CPU-Priorität und gibt CPU-Leistung für andere Prozesse frei, Ionice senkt die Festplattenpriorität und gibt Festplatten-E/A für andere Prozesse frei):

sudo nice -n19 ionice -c2 -n7 tar czf /media/masi/ntfsDisc/backup_home.tar.gz $HOME/

Dadurch wird die Priorität des Prozesses verringert, sodass andere Prozesse nicht verlangsamt werden, während Sie an der Maschine arbeiten. Ansonsten wird weiterhin versucht, den Prozess so schnell wie möglich abzuschließen und Ihre Lüfter zum Hochfahren zu bringen.

Wenn Sie den Spitzenstromverbrauch wirklich reduzieren möchten/müssen (weil Ihr System überhitzt oder die Lüfter Sie nachts wecken), können Sie einen der folgenden Ansätze versuchen:

Eine aufwändigere Lösung wäre, nicht alles auf einmal zu komprimieren, sondern Verzeichnis für Verzeichnis (fügen Sie diesen Code in eine Datei namens backup_home.sh ein, machen Sie sie ausführbar und führen Sie sie über aus sudo backup_home.sh):

#!/bin/bash
OLDIFS=$IFS
IFS='
'
for dir in $(ls -d1 $HOME/*); do
   nice tar rf /media/masi/ntfsDisc/backup_home.tar $HOME/
   sleep 10
done;
gzip /media/masi/ntfsDisc/backup_home.tar
IFS=$OLDIFS

Beachten Sie jedoch, dass der Gesamtstromverbrauch dadurch nicht reduziert wird, sondern sich lediglich über einen längeren Zeitraum verteilt (wodurch die Wahrscheinlichkeit steigt, dass eine Datei während der Sicherung geändert wird). Außerdem wird die Last dadurch nicht gleichmäßig verteilt, da wahrscheinlich nicht alle Ordner die gleiche Größe haben. Ich empfehle Ihnen dringend, nice zu verwenden und den Rest dem System zu überlassen.

Und wenn Sie wirklich tiefer in die Materie eintauchen möchten, können SieCPU-Frequenzskalierungum Ihre CPU für die Dauer des Backups manuell zu untertakten

Antwort2

Ein Ansatz wäre, parallele Komprimierung zu verwenden, um alle Kerne Ihres Systems zu nutzen und so die Komprimierungszeit zu verkürzen. Dadurch wird die Belastung Ihres Systems zwar nicht verringert, es wird jedoch für die kürzeste Zeit belastet!

Wie das geht, erfahren Sie beispielsweise in diesem Q&A:Nutzung von Multi-Core für Targzip-Bzip-Komprimierung/-Dekomprimierung

Zum Beispiel:

tar cf - paths-to-archive | pigz > archive.tar.gz

Antwort3

Der Befehl

tar czf /media/masi/ntfsDisc/backup_home.tar.gz $HOME/

ist das gleiche wie das hier:

tar cf - $HOME/ | gzip > /media/masi/ntfsDisc/backup_home.tar.gz

Als Sie ausgeführt haben top, zeigte sich, dass das Gzip-Programm etwa 100 % eines CPU-Threads beanspruchte. Die NTFS FUSE-Software beansprucht ebenfalls eine CPU-Menge ungleich Null, aber im Grunde sind Sie wegen dieses Gzip-Programms CPU-gebunden. Ihre durchschnittliche Auslastung liegt bei etwa 2, und mit 2 Kernen mit jeweils 2 Threads überlasten Sie Ihr System nicht.

Wenn Ihr Ziel jedoch darin besteht, die maximale CPU-Auslastung zu reduzieren (weil die Lüfter mit maximaler Leistung laufen), können Sie dies ganz einfach erreichen, indem Sie die Geschwindigkeit der an gzip übermittelten Daten verringern.

Du hast den Test durchgeführt

tar cf - $HOME/ | pv | gzip > /media/masi/ntfsDisc/testbackup.tar.gz

und pv gab an, dass die maximale Übertragungsrate in gzip 20 MiB/s betrug. Ich würde empfehlen, diese zu halbieren, indem Sie pv die -L 10mOption geben.

tar cf - $HOME/ | pv -L 10m | gzip > /media/masi/ntfsDisc/testbackup.tar.gz

Versuchen Sie, die Ratenbegrenzung nach oben oder unten anzupassen, bis Sie die gewünschte CPU-Auslastung erreichen.

verwandte Informationen