dingsbums schrieb:
Wenn du nur diesen einen Prozess limitieren willst und keine Lust hast, ihn jedes Mal per extra Befehlsaufruf "einzubremsen", würde ich einfach dauerhaft ein Skript mitlaufen lassen, welches alle x Sekunden auf den fraglichen Prozessnamen prüft und alle passenden Prozess-ID's dann per renice niedriger priorisiert.
Das ist unnötiger Overhead und echt eine Krücke. Abgesehen davon, dass man das deutlich eleganter machen kann.
seahawk1986 schrieb:
Der Weg über die Prozesspriorität (wie mit nice) hat den Vorteil, dass Prozesse mit niedriger Priorität (also hohem nice-Wert) weniger ausgebremst werden, wenn das System sonst nichts zu tun hat - da kann der Scheduler dann einfach dem Prozess mehr Timeslots geben, wenn die frei sind.
Genau.
Mit ionice kann man sowas auch für I/O machen, falls du Bedenken hast, dass das Lesen und Schreiben durch das Programm ein limitierender Faktor für den Rest des Systems sein könnte.
Das hängt allerdings vom IO-Scheduler ab. Ich musste eine Udev-Regel schreiben, damit meine Platten anstatt "mq-deadline" den "bfq" bekommen, der IO-Prioritäten unterstützt. (Ich brauchte das, damit der regelmäßige btrfs scrub
nicht alle anderen Aktivitäten beeinflusst.)
Nachdem die Prozesse von einem Skript gestartet werden, spricht IMHO nichts dagegen da direkt ein nice vor den Ghostscript-Aufruf zu setzen.
Das erscheint mir auch die beste Lösung.
Sobald du Ressourcen hart limitierst, beschränkt das die maximale Geschwindigkeit oder im schlimmsten Fall die erfolgreiche Ausführung der Prozesse. Ein Memory Limit lohnt sich in dem Kontext nicht unbedingt, denn wenn die zugeteilte Menge nicht ausreicht, schlägt die Ausführung des Programms einfach fehl - das macht man eher auf Maschinen, auf denen mehrere User bzw. deren Prozesse unterwegs sind, um zu verhindern, dass jemand sich ein zu großes Stück vom Kuchen holt.
Letzteres würde man aber besser mit Cgroups machen aus dem gleichen Grund, den Du oben genannt hast: wenn kein anderer Prozess den Speicher braucht, dann kann sich ein hungriger auch mehr bzw. alles nehmen. Oder?
Was bei Programmen mit Multi-Core Unterstützung (die es schaffen alle Kerne auszulasten) ggf. Sinn machen kann ist die Zahl der nutzbaren Kerne zu limitieren - z.B. kann man mit taskset Prozesse an Kerne binden: https://baiweiblog.wordpress.com/2017/11/02/how-to-set-processor-affinity-in-linux-using-taskset/
Aber das ist auch wieder so eine harte Limitierung. Wenn die anderen Kerne nicht benötigt werden, dann dauert die Arbeit möglicherweise länger. Ich finde es da besser mit weichen Begrenzungen zu arbeiten, die nur greifen, wenn die Ressourcen anderweitig benötigt werden.