Verwenden einer netten Planungspriorität mit dem Cron-Skript tar / gzip

Ich mache große Backups, die meinen Server bei der Verwendung stark belasten tar/gzip. Ich habe die Aufgabe als Cronjob eingerichtet, der auf mein Skript zugreift, das die Sicherung verwaltet. Ich weiß, dass nicedies möglicherweise in dieser Situation hilfreich sein kann, bin mir aber nicht sicher, wie ich es richtig einsetzen soll.

Ich habe die folgenden Befehle in meinem Skript:

tar -cf 
gzip -9

Würde ich einfach den niceBefehl davor hinzufügen , um die Priorität zu verringern?:

nice -n 13 tar -cf 
nice -n 13 gzip -9

Gibt es irgendwelche Einschränkungen bei der Verwendung dieses Ansatzes? Vielen Dank.

cron nice

— Joe Habadas
quelle

Es kann nichts schlimmer machen, also ist es sicher zu versuchen und zu sehen.

Ich sehe kein Problem. Aber warum schreibst du nicht ein Skript und rufst es mit auf nice? Sie planen den gesamten Sicherungsprozess. Überprüfen Sie auch den ioniceBefehl.

— Eduardo Ramos

@EduardoRamos, daran habe ich eigentlich gedacht. Ich bin nicht vertraut ionice, also muss ich es überprüfen. Das Skript wird von einem Cronjob aufgerufen - würde ich das also einfach in Crontab anhängen? zum Beispiel : 30 22 * * * /bin/sh nice -n 13 myscript.sh. Ich bin mir auch nicht sicher, aber wenn ich dies innerhalb des Skripts tun würde, würde die zweite nicht die erste nicebeeinflussen? was bedeutet, dass gzip ein Teilprozess von Teer ist?

— Joe Habadas

Ja. Wenn Ihr Skript dies tut tarund gzipdanach, wirkt nicesich dies auf das Skript und den gesamten untergeordneten Prozess aus.

— Eduardo Ramos

Ich bemerkte, dass andere an anderer Stelle vorgeschlagen hatten * * * * * /usr/bin/nice -n 13 ...- würde ich es also nicht verwenden /usr/bin/sh?

— Joe Habadas

Antworten:

Es gibt Vorbehalte zu beachten. Da die Frage kein genaues Betriebssystem angibt (impliziert jedoch, dass es sich um ein Unix-ähnliches Betriebssystem handelt), hängt die Liste der Einschränkungen von einem bestimmten Betriebssystem und einer bestimmten Version ab. Die wichtigsten zu beachten sind:

nicesoll beeinflussen, wie viel CPU-Zeit einem Prozess zugewiesen wird, nicht jedoch, wie viel RAM oder E / A-Kapazität. Anstelle des beabsichtigten Effekts umfassen andere mögliche Ergebnisse:

Die Sicherung dauert länger, da weniger CPU-Zeit zur Verfügung steht. Aber es wird genauso viel RAM verbrauchen wie früher und jetzt wird es diesen RAM für längere Zeit verwenden. Das System wird verlangsamt, weil für andere Zwecke weniger RAM zur Verfügung steht, und diese Langsamkeit hält länger an als früher.
Die Verwendung von nicehat überhaupt keine Auswirkung, da der Sicherungsprozess zunächst an die E / A gebunden war und die E / A-Planung davon nicht betroffen ist nice. Wenn es sich bei dem Betriebssystem um eine neuere Linux-Version handelt, kann die E / A-Planung davon niceabhängen, welche ioniceEinstellung verwendet wird oder nicht .

Darüber hinaus hängt auch die genaue Auswirkung auf die CPU-Planung stark vom jeweiligen Betriebssystem und den Einstellungen ab. Einige Kernel verfügen über Einstellungen, mit denen ein Prozess mit einer höheren oder niedrigeren Priorität ausgeführt werden kann als mit dem niceBefehl erreichbar.

Eine Einschränkung, die ich mir selbst begegnet bin, scheint spezifisch für Ubuntu 14.04 zu sein. In der Standardkonfiguration werden Prozesse zu Planungszwecken gruppiert. Jede Gruppe erhält dann einen angemessenen Anteil an der CPU-Zeit. niceDies wirkt sich nur darauf aus, wie die CPU-Zeit Prozessen innerhalb einer solchen Gruppe zugewiesen wird, nicht jedoch darauf, wie viel jeder Gruppe zugewiesen wird. Für mich hat dies die Verwendung von vollständig untergraben nice, da ein Prozess mit niedriger Priorität den Prozessen in verschiedenen Gruppen immer noch CPU-Zeit nehmen könnte.

— Kasperd
quelle

"... und die E / A-Planung bleibt davon unberührt nice." Ich würde vorschlagen, dass Sie die ioniceManpage lesen, da dies standardmäßig nicht der Fall ist.

— Matthew Ife

Es ist wirklich nur das, CPUwas betroffen ist, wenn mein Skript das trifft tar/gzip. Dies führt wiederum zu Engpässen für Momente, in denen der Server nur noch crawlt. Sie sprechen jedoch großartige Punkte über die Vorbehalte an, und ich kann sehen, dass dies wirklich ein Balanceakt ist und oft eine feine Grenze zwischen der Verbesserung oder möglicherweise der Verschlechterung besteht.

— Joe Habadas

Vielleicht können Sie CGroup verwenden. Sie können die Ressourcen für Ihren Prozess gut steuern. Gute Dokumentation erhalten Sie hier: access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/…

— Eduardo Ramos

@MatthewIfe Was Sie erwähnen, ist betriebssystemspezifisch. Die Frage gibt jedoch nicht an, welches Betriebssystem verwendet wird. Was ich gesagt habe ist, dass es ein mögliches Ergebnis ist, und ich werde zu dieser Aussage stehen, auch wenn es nicht auf jeder Version jedes Betriebssystems möglich ist, für das die Frage gelten könnte.

— Kasperd

Ich würde einen anderen Ansatz wählen ...

Nein, ich würde nicht damit herumspielen nice. Und gzipist das nicht toll? Außerdem verwenden Sie gzip -9die Komprimierungsrate auf Kosten der CPU. Benötigen Sie wirklich diese Komprimierungsstufe gegenüber der Standardeinstellung (Stufe 6)?

Wird Ihr System so stark belastet, wenn Sie gzip Level 9 nicht verwenden?

Was sind die Spezifikationen Ihres Servers? Wie viele und welche Art von CPUs haben Sie?cat /proc/cpuinfo

Wenn Sie mehrere CPUs haben, würden Sie pigzstattdessen die Verwendung in Betracht ziehen ? Es ist multithreaded, etwas effizienter und kann die Ressourcen auf Ihrem System viel besser nutzen.

Einige Tests mit einer 1,8-GB-Datei:

Standard gzip(-6 Komprimierungsstufe)

Original file size: 1.8G    CHL0001.TXT 
Compression time: 0m18.335s
Compressed file size: 85M   CHL0001.TXT.gz
Decompression time: 0m6.300s

gzip -9 (höchste Komprimierung)

Original file size: 1.8G    CHL0001.TXT
Compression time: 1m29.432s
Compressed file size: 75M   CHL0001.TXT.gz
Decompression time: 0m6.325s

pigz (-6 Kompressionsstufe)

Original file size: 1.8G    CHL0001.TXT
Compression time: 0m1.878s
Compressed file size: 85M   CHL0001.TXT.gz
Decompression time: 0m2.506s

pigz -9 (höchste Komprimierung, Multithread)

Original file size: 1.8G    CHL0001.TXT
Compression time: 0m5.611s
Compressed file size: 76M   CHL0001.TXT.gz
Decompression time: 0m2.489s

Fazit: Lohnt sich die zusätzliche Komprimierung für die erheblich längere Zeit, die für die Komprimierung der Daten aufgewendet wird?

— ewwhite
quelle

Interessante Ergebnisse. Der Grund für die Verwendung der hohen Komprimierung ist, dass ich SQL-DBs sichere, von denen einige vorbei sind 20 GB. Ich habe keine Leasinggeberkomprimierung versucht, da der Speicherplatz eine Rolle spielt. Ich muss die Ergebnisse der Verwendung einer Leasinggeberkomprimierung mit den Festplatten- und CPU-Kosten vergleichen. Da die Daten so groß sind, ist dies leider nicht schnell zu testen. Ich habe noch nie davon gehört pigz, also danke für die Empfehlung - ich bin immer offen für Alternativen :)

— Joe Habadas

Das Parallelisieren der Komprimierung hilft nicht, wenn die Box CPU-gebunden ist.

— August

Mir ist klar, dass dies von der ursprünglichen Frage abweicht, aber es bleibt beim Thema Effizienz (Sie erwähnen "enorme Belastungen auf meinem Server") ...

Ich schließe (oder vermute!) Aus dem, was Sie gepostet haben, dass Sie tareine Datei mit einer Reihe von Dateien erstellen und dann gzipdas Ergebnis ermitteln. Sie können sich viel Festplatten-E / A (und temporären Speicherplatzbedarf) sparen, indem Sie eine direkt in die andere leiten:

tar cf - /path/to/stuff | gzip > archive.tar.gz

Möglicherweise hat dies einen signifikanten Einfluss auf die insgesamt verstrichene Zeit.

— Chris
quelle