CPU Auslastung beim Komprimieren (Zip) begrenzen?

[mgutt]

Ich erstelle gerade eine Zip-Datei von einem größeren Ordner. Parallel gab es noch einen Kopierprozess über SMB. Dessen Geschwindigkeit ist nun stark gefallen, was aber auch logisch erscheint, da die CPU durch das Packen der Dateien am Limit läuft. Kann man das irgendwie begrenzen, dass z.B. max. 50% Leistung für FileStation bzw. für den Komprimiervorgang zugeteilt werden?

 

[dil88]

Ist mir nicht bekannt und m.W. auch auf der Shell nicht im Rahmen des normalen DSM möglich. Ich kenne da aber nur DSM 5.2, vielleicht ist es bei DSM 6.0 möglich. Man kann sich per IPKG (sprich EBI) aber ein nice installieren.

 

[mgutt]

Du meinst dann komprimieren über die Kommandozeile? Ne wenn hätte ich das schon gerne integriert. Also dass ein Package z.B. den Prozess drosselt. Wenn ich das richtig verstehe müsste man das ja über "chrt -i {process}" hinbekommen:
https://linux.die.net/man/1/chrt

D.h. laufende Prozesse überwachen und wenn 7z auftaucht, dann diesem Prozess die niedrigste Priorität zuweisen.

 

[dil88]

Nein, nicht komprimieren über die Kommandozeile, sondern "nicen" des anderweitig gestarteten Kompressionsprozesses.

 

[mgutt]

Ok, ich habe Perl, dann den Fix:
http://www.synology-forum.de/showthread.html?82117-Perl-5-24-0-0066-CGI-Fix

und dann EBI installiert:
http://www.synology-forum.de/showthread.html?68335-EBI-Easy-Bootstrap-Installer

Anschließend noch iPKGui und die linux-utilities installiert:


Neben "renice" habe ich dadurch auch "chrt", was laut meiner Recherche viel tiefgreifender funktioniert als "renice" alleine.

Ich habe dann die Prozess-ID über "top" herausgesucht und dann "chrt" und "renice" angewendet:


Bei "chrt" entspricht "-i" dem Wert "SCHED_IDLE" und damit dem geringsten Wert:
https://barro.github.io/2016/02/being-a-good-cpu-neighbor/

SCHED_IDLE: the lowest priority scheduling policy. Not affected by dynamic priorities. This equals to nice level priority of 20.

und bei "renice" soll der Wert 19 die geringste Priorität sein:
https://wiki.ubuntuusers.de/nice/

wobei -20 die höchste Priorität (=meiste Rechenleistung) und 19 die niedrigste Priorität (=geringste Rechenleistung) ist

Kann gut sein, dass man "renice" dann gar nicht mehr braucht, habe ich nicht getestet.

Die Auswirkungen sind aber auch marginal:


Meinst Du ich könnte es mit "ignore_nice_load" probieren?
https://wiki.ubuntuusers.de/Prozessortaktung/

Ab Ubuntu 9.04 werden auch Prozesse niedriger Priorität (kleiner nice-Wert) bei dynamischen Govenor (z.B. ondemand) bei Auslastung mit hoher Taktfrequenz bearbeitet. Dies kann bei Hintergrundprozessen (z.B. BOINC) unerwünscht den Stromverbrauch erhöhen. Dies wird mit dem Setzen der Datei ignore_nice_load auf 1 geändert. Die einfachste Methode ist es, dies mit Hilfe der sysfsutils gleich beim Start festzulegen. Dazu muss das Paket sysfsutils installiert sein.

Der Sinn davon ist, dass alle Prozesse mit einem "nice" größer 0 (also geringerer Priorität) nicht in der Lage sind die CPU hochzutakten. Wobei fraglich ist was passiert, wenn der SMB Prozess die CPU nach oben bringt.

 

[dil88]

Die CPUs Deiner DiskStations haben keinen variablen Takt, es gibt keinen Turbo-Takt. Deshalb wirst Du an der Stelle nicht weiterkommen. Ich würde mir an Deiner Stelle einmal mit htop experimentieren. Das zeigt Dir für alle Prozesse den nice-Wert an und ermöglicht Dir, den Wert für einen Prozess interaktiv zu erhöhen oder zu senken.

 

[mgutt]

Danke für den Tipp. Durch "htop" sehe ich jetzt erst, dass 7z aus 3 Prozessen besteht. Ich habe dann mal alle drei mit "chrt" in "SCHED_IDLE" versetzt und schon sieht das ganz anders aus:


Die CPU-Last war zwar nach wie vor bei 100%, aber diesmal hat der SMB Prozess das erste mal 7z in der "htop"-Liste überholt, wurde also mehrmals bevorzugt behandelt.

Übrigens habe ich es innerhalb "htop" auch mit "nice" und der Taste F8 probiert. Also die Priorität auf 19 herabgesetzt, aber das hat Null gebracht. Obwohl 3/4 vom CPU Balken in "htop" blau gefärbt war, also klar die niedrige Priorität zu erkennen war. Bei "chrt" wird übrigens nichts blau.

Auch noch eine Idee wäre mit "taskset" 7z auf einen Kern zu binden:
http://unix.stackexchange.com/a/23109/101920

 

[dil88]

Wenn sich der Ansatz mit der Beschränkung auf einen Kern umsetzen ließe, wäre das in meinen Augen ein sehr cleverer Ansatz für Deine Problemstellung. Ansonsten danke für die Details im Zusammenhang mit 7z.

 

[mgutt]

Also es geht beides sehr gut wie ich finde. Erstmal "chrt" wie zuvor genannt, aber auch das Binden der Prozesse an einen Kern mit folgendem Befehl:

taskset -c -p 0 $PID

Standardmäßig kann 7z beide CPUs nutzen, d.h. der Befehl zum Zurücksetzen ist dieser:

taskset -c -p 0,1 $PID

Die Frage ist nun aber wie man das intelligent umsetzen könnte. Der smb-Prozess war von Haus aus im Gegensatz zu 7z auf einen Kern gebunden. So blieb mir nur die Möglichkeit 7z den anderen Kern zuzuweisen. Doch nutzt der smb-Prozess immer diesen einen Kern und gilt das für alle Prozesse, die größere Last verursachen können. Ich denke mal nicht.

Daher müsste man es wenn so machen:
- jede Minute auf die Existenz von 7z Prozessen prüfen
- wenn 7z gefunden, dann die Last der anderen Prozesse jede Minute prüfen
- jeder andere Prozess, der mind. 10% Last verursacht wird auf seine zugewiesenen Kerne geprüft
- wenn 0,1 oder 1, dann bekommt 7z Kern 0 zugewiesen
- wenn 0, dann bekommt 7z Kern 1 zugewiesen
- sobald die anderen Prozesse wegfallen bekommt 7z sein 0,1 zurück

Mit chrt ist es dagegen viel einfacher:
- jede Minute auf die Existenz von 7z Prozessen prüfen
- wenn 7z gefunden, dann "SCHED_IDLE" zuweisen