claim.gif
Linux Magazin Linux User Easy Linux Ubuntu User International Linux Community
Erschienen in EasyLinux 04/2008   »   Ausgabe bestellen

Programme mit top, ps, kill, pidof, nice, renice steuern

Prozesse im Griff

Hans-Georg Eßer


OpenOffice hängt -- jetzt heißt es, schnell das Programm abzuschießen, bevor der Speicher voll läuft und das System unbenutzbar wird. Am schnellsten geht es auf der Shell.

Stabilität ist einer der Punkte, der Linux zu Zeiten von Windows 95 populär gemacht hat. Eine der Gründe dafür ist, dass Linux alle laufenden Programme (die "Prozesse" heißen) sauber voneinander trennt, so dass eine fehlerhaft programmierte Anwendung beim Absturz keine weiteren Programme oder gar das ganze System mit in den Abgrund reißen kann. Als Multitasking-Betriebssystem kann Linux nahezu beliebig viele Programme parallel ausführen; mit wachsender Prozesszahl wird das Gesamtsystem nur immer langsamer.


Multitasking: schafft die Möglichkeit, mehr Programme gleichzeitig laufen zu lassen als es Prozessoren im Computer gibt. Dafür ist der Scheduler, ein Teil des Betriebssystems, zuständig: Er teilt jedem Programm stets ein bisschen Rechenzeit zu, bevor er ein anderes Programm auswählt. Durch die kurzen Abstände zwischen den Programmwechseln entsteht für Benutzer der Eindruck, dass alle Anwendungen gleichzeitig laufen.

Jedes Programm, das Sie starten, wird zu einem Prozess; läuft dasselbe Programm mehrmals, gibt es auch mehrere Prozesse. Die Prozesse sind voneinander unabhängig und belegen unter anderem Speicher und CPU-Zeit.

Prozessmanager

Die grafischen Oberflächen wie KDE und Gnome bringen GUI-Tools für die Prozessüberwachung und -steuerung mit, unter KDE etwa der Performance-Monitor (ksysguard) und unter Gnome der GNOME-Systemmonitor (gnome-system-monitor). Arbeiten Sie unter KDE mit den Standardeinstellungen, gibt es für das KDE-Tool sogar eine Tastenkombination: [Strg-Esc] ruft das Tool auf und zeigt direkt die Prozessliste an (Abbildung 1).

Abb. 1: Die Prozesse präsentiert der KDE-Performance-Monitor in einer grafischen Übersicht.

Über diese grafischen Tools erhalten Sie nicht nur eine Übersicht, sondern können die laufenden Prozesse auch beeinflussen -- etwa mehr oder weniger gewaltsam abbrechen. (Es gibt tatsächlich zwei Abbruchvarianten, von denen eine vorsichtiger aber nicht immer erfolgreich ist.)

Traditionell steuern Sie die Prozesse aber über Shell-Befehle, und wie es für Artikel im Guru-Training üblich ist, erreichen Sie Ihre Ziele in der Shell häufig schneller. Im Folgenden stellen wir Ihnen die wichtigsten Kommandos vor, mit denen Sie die Prozessliste betrachten und einzelne laufende Programme im Detail beeinflussen können: Dazu zählt nicht nur der Programmabbruch, sondern es sind auch Pausen und das Schneller- oder Langsamermachen möglich.

Der den Speicher frisst

Manche Programme belegen sehr viel Speicher -- und mit zunehmender Laufzeit immer mehr. Typische Vertreter dieser speicherhungrigen Art sind Browser wie Mozilla, Firefox und Opera: Sie laden z. B. häufig Plug-ins für Flash- oder sonstige multimediale Inhalte in den Speicher. Gerade Plug-ins sind oft problematisch, zumal sie gelegentlich den Browser zum Einfrieren bringen.

Mit dem Tool top werfen Sie einen Blick auf die größen Speicherfresser. Dazu öffnen Sie zunächst ein Terminalfenster, maximieren es und geben dann den Befehl top ein. Nach dem Programmstart zeigt top eine Liste von Prozessen an und aktualisiert diese ständig -- es sortiert allerdings zunächst nach der prozentualen CPU-Nutzung (Spalte %CPU). Das ändern Sie wie folgt: Drücken Sie nacheinander [Umschalt-O], [O] und [Eingabe]:

Danach sieht die Anzeige wie in Abbildung 2 aus. Wichtig ist hier die rot hervorgehobene Spalte VIRT, die anzeigt, wie viel virtuellen Speicher die Prozesse verbrauchen. Ganz oben in der Liste stehen in diesem Beispiele die Prozesse opera und beagled (ein Hintergrundprogramm, das für die Desktop-Suchmaschine Beagle nach neuen Dateien sucht).

Abb. 2: Sortieren Sie in "top" nach Speicherverbrauch, erkennen Sie auf einen Blick die größten Speicherfresser.

Wenn der Rechner ständig auf die Festplatte zugreift, ist der Hauptspeicher knapp geworden: Linux "swappt", das heißt: Es lagert Speicherbereiche einzelner Prozesse auf die Platte aus, um wieder Platz zur Verfügung zu haben. Will ein Programm dann weiterarbeiten und derart ausgelagerte Daten nutzen, müssen diese aus der Platte wieder ins RAM geladen werden -- wofür das System aber erneut Platz freischaufeln muss. So entsteht, wenn Sie insgesamt zu viele Prozesse (mit zu großem Speicherbedarf) ausführen, ein Kreislauf, in dem Linux permanent Daten zwischen Platte und RAM hin und her bewegt.

Das Problem können Sie nur beheben, indem Sie einzelne Programme (am besten solche, die viel Speicher verbrauchen) schließen. Tritt die Situation ständig auf, sollten Sie überlegen, einen zusätzlichen Speicherriegel einzubauen. Die Übersicht in top sagt Ihnen nun, welche Programme Sie beenden sollten, um die größte Menge Speicher wieder freizugeben.

Mach mal Pause

Gelegentlich reicht es auch aus, ein ressourcenfressendes Programm vorübergehend zu unterbrechen -- dabei ist es egal, ob diese Anwendung vor allem Rechenzeit oder Speicher beansprucht: Hat sie einmal angehalten, kann Linux den Prozessspeicher auf Platte auslagern und wird ihn nicht wieder anfordern, bis Sie das Programm reaktivieren. Das Swappen hört dann schnell auf.

Ein Blick in die Prozessliste verrät Ihnen, wie alle Prozesse heißen und welche Prozess-IDs (PID) sie haben: Diese IDs sind eindeutige Nummern, anhand derer Linux (und auch Sie) die Prozesse voneinander unterscheiden können. In der Übersicht des Programms top stehen die PIDs in der ersten Spalte, die Namen in der letzten. Taucht das Programm dort nicht auf (die Liste ist ja nicht vollständig), betrachten Sie mit dem Kommando ps die vollständige Liste. Am besten leiten Sie die Ausgabe über | less in einen Pager und verwenden die ps-Parameter ux (ohne einleitendes Minuszeichen), um alle (eigenen) Prozesse zu sehen:

ps ux | less

In der Ausgabe von ps finden Sie die Prozess-ID in der zweiten Spalte und den Programmnamen in der letzten (Abbildung 3). Wenn Sie die Prozess-ID des betroffenen Programmes gefunden haben, schicken Sie dem Prozess einfach über den kill-Befehl das Signal STOP, dann hält er an. Haben Sie sich aus der Prozessliste nur den (genauen!) Programmnamen gemerkt, verwenden Sie statt kill das Tool killall, welches das Signal an alle Prozesse mit diesem Namen schicken wird. Die beiden Befehlsvarianten sind also:

kill -STOP PID
killall -STOP Prozessname

Bei grafischen Anwendungen bemerken Sie dann, dass der Inhalt des Fensters nicht mehr aktualisiert wird.

Abb. 3: Die Prozessliste mit "ps" zeigt unter anderem die PID und den Prozessnamen (markierte Spalten) an.

Soll der Prozess seine Arbeit wieder aufnehmen, schicken Sie ihm erneut ein Signale -- nach dem STOP geht es jetzt mit CONT (continue, fortsetzen) weiter. Auch hier haben Sie die Wahl, ob Sie einen einzelnen Prozess über dessen ID oder eine Gruppe von Prozessen über den Programmnamen ansprechen wollen:

kill -CONT PID
killall -CONT Prozessname

Etwas freundlicher, bitte

Wenn Ihnen bekannt ist, dass ein Programm dazu neigt, sich in den Vordergrund zu drängen (also besonders viel CPU-Zeit zu beanspruchen), können Sie es gleich beim Start in seine Schranken weisen: Fordern Sie es einfach auf, sich gegenüber anderen Prozessen "freundlich" zu verhalten, auf Englisch: nice. Das gleichnamige Kommando (nice) stellen Sie einem Programmaufruf voran, wobei Sie zusätzlich einen "Nice-Faktor" zwischen 1 und 19 angeben -- je größer diese Zahl ist, desto weniger Rechenzeit wird das so gestartete Programm erhalten.

Um etwa ein Programm rechne im Hintergrund Berechnungen durchführen zu lassen, dabei aber recht wenig CPU-Zeit zu verbrauchen, könnten Sie es mit dem Kommando

nice 10 rechne

starten. Den Wert 10 könnten Sie hier auch weglassen und nur nice rechne eingeben, denn 10 ist der Vorgabewert für den Fall, dass Sie keinen expliziten Nice-Faktor angeben.

Auch wenn eine Anwendung bereits läuft, können Sie ihren Nice-Wert nachträglich anpassen: Dazu dient das Kommando renice. Es erwartet zwei Argument: den neuen Nice-Wert und die Prozess-ID. Haben Sie also das Programm rechne schon gestartet und finden über die Prozessliste heraus, dass es die PID 12345 hat, können Sie mit

renice 10 12345

den Nice-Wert auf 10 erhöhen. Ein Programm, das die Nice-Werte aller Prozesse mit einem bestimmten Namen ändert (vergleichbar mit killall), gibt es nicht, Sie können aber das Tool pidof verwenden, um es schnell selbst zu erstellen: Legen Sie im Verzeichnis /usr/local/bin eine Datei reniceall an und schreiben Sie folgende zwei Zeilen hinein:

#!/bin/bash
for PID in $(pidof $2); do renice $1 $PID; done

Speichern Sie das Programm und machen Sie es mit

chmod a+x /usr/bin/reniceall

ausführbar. (Sowohl für das Erstellen der Datei als auch für diese Rechteänderung sind Root-Rechte nötig.) Jetzt können Sie analog zu killall auch ein Kommando der Form

reniceall 10 rechne

absetzen:

$ reniceall 5 bash
15097: Alte Priorität: 0, neue Priorität: 5
15078: Alte Priorität: 0, neue Priorität: 5
15060: Alte Priorität: 0, neue Priorität: 5
15044: Alte Priorität: 0, neue Priorität: 5

Übrigens kann renice den Nice-Wert immer nur erhöhen, also z. B. vom Standardwert 0 auf 10 und dann erneut von 10 auf 15. Nur mit Administratorrechten (also als Benutzer root) können Sie das rückgängig machen und den Wert wieder erniedrigen -- dabei darf root einem Prozess sogar mehr Rechenzeit als üblich zuweisen -- dazu verwenden Sie einen negativen Nice-Wert (zwischen -1 und -20): Je kleiner der Wert (also je größer die Zahl hinter dem Minuszeichen) ist, desto mehr Rechenzeit erhält das Programm. Um für ein laufendes Programm maximale Performance herauszuschlagen, werden Sie also mit su zu root und setzen dann den Nice-Wert der Anwendung auf -19.

Letztes Mittel: Abbruch

Programme, die abgestürzt sind, können Sie mit renice nicht mehr beeindrucken; auch eine Unterbrechung mit kill -STOP schafft das Problem nicht dauerhaft aus der Welt: Hier hilft nur noch, das Programm zu beenden.

Wie in der Einleitung bereits angesprochen, gibt es zwei mögliche Wege, einen Programmabbruch einzuleiten: Wenn die Anwendung nicht mehr reagiert (Ihnen also der Weg eines ordentlichen Ausstiegs über einen Menüpunkt wie Datei / Beenden verwehrt wird), finden Sie zunächst die Prozess-ID oder den Prozessnamen heraus.

Versuchen Sie dann zunächst, den Prozess über das TERM-Signal (terminate) zu beenden -- das ist die freundlichere Variante, die der Anwendung noch eine Chance gibt, das drohende Ende zu bemerken und beispielsweise offene Dateien zu schließen, bevor sie sich freiwillig beendet. Die dafür nötigen Befehle (je nachdem, ob Sie mit der PID oder mit dem Prozessnamen arbeiten wollen) sind:

kill -TERM PID
killall -TERM Prozessname

Die Option -TERM dürfen Sie auch weglassen, weil TERM das Standardsignal der Befehle kill und killall ist. Zeigt der Befehl keine Wirkung, greifen Sie zum letzten Mittel und schicken das Signal KILL, das den betroffenen Prozess sofort und ohne Vorwarnung abbricht:

kill -KILL PID
killall -KILL Prozessname

In seltenen Fällen ist nicht einmal dieses Kommando erfolgreich; dann müssen Sie abwarten, ob der Prozess von alleine ein Ende findet, oder den Rechner neu starten. Prozesse, die auf das KILL-Signal nicht reagieren, verbrauchen allerdings typischerweise auch keine Rechenzeit mehr, so dass Sie einfach bis zum nächsten regulären Reboot warten können. (hge)

Dieser Online-Artikel kann Links enthalten, die auf nicht mehr vorhandene Seiten verweisen. Wir ändern solche "broken links" nur in wenigen Ausnahmefällen. Der Online-Artikel soll möglichst unverändert der gedruckten Fassung entsprechen.

Druckerfreundliche Version | Feedback zu dieser Seite | Datenschutz | © 2014 Medialinx AG | Last modified: 2008-09-26 18:30

[Linux-Magazin] [LinuxUser] [Linux-Community] [Admin-Magazin] [Ubuntu User] [Smart Developer] [Linux Events] [Linux Magazine] [Ubuntu User] [Admin Magazine] [Smart Developer] [Linux Magazine Poland] [Linux Community Poland] [Linux Magazine Brasil] [Linux Magazine Spain] [Linux Technical Review]