iX 6/2016
S. 125
Praxis
Tools & Tipps
Aufmacherbild

Prozessverwaltung: Niceness im Griff

Einfach nett

Die Frage, welche Prozesse welche Priorität bekommen, muss der Administrator nicht allein dem Kernel überlassen. Eingreifen kann er mit Bordmitteln wie nice, renice und ionice.

Unixe sind von Haus aus Mehrprozess- und Mehrbenutzersysteme. Ihr Konzept der Niceness erlaubt Administratoren das bedarfsgerechte Zuweisen von Systemressourcen an die unterschiedlichen Tasks. Der Begriff Niceness bildet den Kehrwert zur Prozesspriorität: Je weniger ein Thread oder Prozess um Rechenzeit bettelt, desto netter ist er. Die meisten unixoiden Betriebssysteme stellen ihn auf einer Skala dar, die von -20 (Egomane) bis 19 (selbstlos) rangiert.

Wer den Befehl nice eingibt, bekommt den Nettigkeitswert der Shell zurück. Diesen Wert erben alle dort gestarteten Prozesse. Erhöhen oder senken kann man ihn beim Aufruf mit nice –n <differenz> <befehl> oder nice –<differenz> <befehl>. Zu unfreundlicherem Verhalten auffordern und in die Prozesse anderer Benutzer eingreifen kann üblicherweise nur root.

Wer die Niceness eines laufenden Prozesses ändern will, greift zu top oder renice. Hat man top laufen, weil man die benötigte Prozess-ID oder PID ermitteln will, kann man die Aufgabe gleich dort erledigen: r öffnet die interaktive Befehlszeile oberhalb der Prozesstabelle. Dort erfragt top die gewünschte PID und den zu setzenden Nice-Wert.

Wer seine Prozesse lieber mit ps verwaltet oder die PID bereits kennt, für den bietet sich renice an. Als erstes Argument will renice, mit oder ohne –n übergeben, den gewünschten Nice-Wert. Das ebenfalls optionale –p weist die folgenden Zahlen als PIDs aus. renice –n 10 –p 3274 3324 und renice 10 3274 3328 erhöhen beide die Niceness der Prozesse 3274 und 3328 auf 10.

Wie bei nice gilt: Prozesse vererben die mit renice gesetzte Niceness an alle danach entstehenden Kinder oder Klone (Threads). Wer bereits laufende Kinder mit erwischen will, muss renice die Prozessgruppe übergeben. Die Process Group ID oder PGID ist unter Linux immer die PID des ersten oder führenden Prozesses einer Gruppe. Beispielsweise tragen die Kernel-Helferdämonen seit ihrer Abspaltung vom eigentlichen Kernelprozess nicht die PID 0, wohl aber die PGID 0. Auch Lazy Daemons wie apached oder winbindd vererben ihre PGID an ihre Kinder weiter. Startprozesse von Window-Managern wie startxfce4 oder kdeinit4 sind ebenfalls PGID-Geber für viele der laufenden grafischen Anwendungen. Mit dem Befehl renice <niceness> –g <pgid> lässt sich die Niceness des kompletten Apache, von Winbind oder des Desktops ändern. Übrigens kann man die PGID ebenso wie die Session ID (SID) aller Prozesse am einfachsten mit ps axj ausgeben, übersichtlicher ist die Baumansicht mit ps axjf.

renice lässt sich aber nicht nur auf Prozesse anwenden. Man kann den Befehl auch auf Benutzer loslassen, um etwa die Priorität eines angemeldeten, aber abwesenden Kollegen zu reduzieren. Zur Angabe der User ID (UID) oder des Namens dient der Schalter –u. Kombiniert man unterschiedliche IDs in einem Aufruf, muss man übrigens nach der Angabe anderer IDs mit –p wieder zur PID zurückschalten. Alternativ führt man die PIDs zuerst an: renice <niceness> <pid1> <pid2> –u <iud> –g <pgid>.

Eines haben nice, renice und der Renice-Befehl in top gemeinsam: Übergibt man ihnen einen Wert außerhalb der Skala von -20 bis 19, übersetzen sie ihn auf den nächstmöglichen der erlaubten Werte. Wer also versehentlich 33 statt 3 abgibt, bekommt statt einer Fehlermeldung einen Prozess mit einer Niceness von 19.

Und jetzt auf die Autobahn

Häufig bildet der Schreib- oder Lesezugriff auf das Speichermedium den Flaschenhals. Ärgerlich ist es, wenn ein Backup- oder anderer Hintergrundprozess mit niedriger Priorität wichtigere Aufgaben blockiert. Hier kann ionice Abhilfe schaffen. Wie renice kann das Programm PIDs, PGIDs und User IDs zum Bestimmen der Prozesse entgegennehmen. Wie nice kann es aber auch Prozesse mit den gewünschten Vorgaben starten.

Anders als die Geschwister arbeitet ionice mit einem zweistufigen Modell: Erst ist die I/O-Scheduling-Klasse zu bestimmen, dann die -Priorität. Klassen können sein: 1 = Realtime, 2 = Best-Effort und 3 = Idle. 0 steht für keine Klasse, der Kernel setzt es aber mit Best-Effort gleich.

Während Idle-Prozesse einfach warten müssen, bis nichts mehr auf dem Medium los ist, haben die Realtime-Geschwister immer Vorfahrt. Deshalb ist hier Vorsicht geboten, ein dumm konfigurierter Realtime-Task kann das gesamte System lahmlegen. Innerhalb der Klassen Realtime und Best-Effort lassen sich die Prozesse einer der acht Prioritätsstufen zuordnen. Auch hier gilt das Prinzip der Niceness: Drängler haben null Niceness, der höchste Wert von 7 gebührt denen, die anderen die Vorfahrt lassen.

Unix-Kernel verwenden meist mehrere I/O-Scheduler. Linux hat derzeit drei im Gepäck. noop ordnet die eingehenden Requests nicht um. Er ist ideal für RAM-Disks und SSDs, bei denen die Reihenfolge der Schreib- und Lesebefehle gleichgültig ist. deadline dagegen versucht, die Laufzeit der Schreib- und Lesebefehle zu minimieren, cfq sucht einen Mittelweg.

Wer cat /sys/block/sda/queue/scheduler eingibt, bekommt alle Scheduler angezeigt, den aktiven in eckigen Klammern. Will man einen anderen aktivieren, gibt man echo <scheduler> > /sys/block/hda/queue/scheduler ein – alte Anweisungen des bisherigen Schedulers bleiben aber noch in Arbeit. (sun)