Linux Professional Institute Learning Logo.
Weiter zum Inhalt
  • Home
    • Alle Ressourcen
    • LPI Lernmaterialien
    • Mitmachen
    • Publishing Partner
    • Publishing Partner werden
    • Über uns
    • FAQ
    • Mitwirkende
    • Roadmap
    • Kontakt
  • LPI.org
103.6 Lektion 1
Thema 101: Systemarchitektur
101.1 Hardwareeinstellungen ermitteln und konfigurieren
  • 101.1 Lektion 1
101.2 Das System starten
  • 101.2 Lektion 1
101.3 Runlevel wechseln und das System anhalten oder neu starten
  • 101.3 Lektion 1
Thema 102: Linux-Installation und -Paketverwaltung
102.1 Festplattenaufteilung planen
  • 102.1 Lektion 1
102.2 Einen Bootmanager installieren
  • 102.2 Lektion 1
102.3 Shared Libraries verwalten
  • 102.3 Lektion 1
102.4 Debian-Paketverwaltung verwenden
  • 102.4 Lektion 1
102.5 RPM und YUM-Paketverwaltung verwenden
  • 102.5 Lektion 1
102.6 Linux als Virtualisierungs-Gast
  • 102.6 Lektion 1
Thema 103: GNU- und Unix-Befehle
103.1 Auf der Befehlszeile arbeiten
  • 103.1 Lektion 1
  • 103.1 Lektion 2
103.2 Textströme mit Filtern verarbeiten
  • 103.2 Lektion 1
103.3 Grundlegende Dateiverwaltung
  • 103.3 Lektion 1
  • 103.3 Lektion 2
103.4 Ströme, Pipes und Umleitungen verwenden
  • 103.4 Lektion 1
  • 103.4 Lektion 2
103.5 Prozesse erzeugen, überwachen und beenden
  • 103.5 Lektion 1
  • 103.5 Lektion 2
103.6 Prozess-Ausführungsprioritäten ändern
  • 103.6 Lektion 1
103.7 Textdateien mit regulären Ausdrücken durchsuchen
  • 103.7 Lektion 1
  • 103.7 Lektion 2
103.8 Grundlegendes Editieren von Dateien
  • 103.8 Lektion 1
Thema 104: Geräte, Linux-Dateisysteme, Filesystem Hierarchy Standard
104.1 Partitionen und Dateisysteme anlegen
  • 104.1 Lektion 1
104.2 Die Integrität von Dateisystemen sichern
  • 104.2 Lektion 1
104.3 Das Mounten und Unmounten von Dateisystemen steuern
  • 104.3 Lektion 1
104.5 Dateizugriffsrechte und -eigentümerschaft verwalten
  • 104.5 Lektion 1
104.6 Symbolische und Hardlinks anlegen und ändern
  • 104.6 Lektion 1
104.7 Systemdateien finden und Dateien am richtigen Ort plazieren
  • 104.7 Lektion 1
How to get certified
  1. Thema 103: GNU- und Unix-Befehle
  2. 103.6 Prozess-Ausführungsprioritäten ändern
  3. 103.6 Lektion 1

103.6 Lektion 1

Zertifikat:

LPIC-1

Version:

5.0

Thema:

103 GNU- und Unix-Befehle

Lernziel:

103.6 Prozess-Ausführungsprioritäten ändern

Lektion:

1 von 1

Einführung

Betriebssysteme, die in der Lage sind, mehr als einen Prozess gleichzeitig auszuführen, werden als Multitasking- oder Multiprozesssysteme bezeichnet. Während echte Simultanität nur dann auftritt, wenn mehr als ein Prozessor zur Verfügung steht, können selbst Einprozessorsysteme die Simultanität nachahmen, indem sie sehr schnell zwischen den Prozessen wechseln. Diese Technik wird auch in Systemen mit vielen äquivalenten CPUs oder symmetrischen Multiprozessorsystemen (SMP) eingesetzt, da die Anzahl der möglichen gleichzeitigen Prozesse die Anzahl der verfügbaren Prozessoreinheiten bei weitem übersteigt.

Tatsächlich kann immer nur ein Prozess zur gleichen Zeit die CPU steuern. Die meisten Prozessaktivitäten sind jedoch Systemaufrufe, d.h. der laufende Prozess überträgt die CPU-Steuerung an den Prozess eines Betriebssystems, damit dieser die angeforderte Operation ausführt. Systemaufrufe sind für die gesamte Kommunikation zwischen den Geräten zuständig, wie Speicherzuweisungen, Lesen und Schreiben von Dateisystemen, Darstellung von Text auf dem Bildschirm, Benutzerinteraktion, Netzwerkübertragungen usw. Durch die Übertragung der CPU-Steuerung während eines Systemaufrufs kann das Betriebssystem entscheiden, ob es die CPU-Steuerung an den vorherigen Prozess zurückgibt oder diese an einen anderen Prozess übergibt. Da moderne CPUs Instruktionen viel schneller ausführen können, als die meiste externe Hardware miteinander kommunizieren kann, kann ein neuer Steuerungsprozess eine Menge CPU-Arbeit verrichten, während zuvor angeforderte Hardwarereaktionen immer noch nicht verfügbar sind. Um eine maximale CPU-Auslastung zu gewährleisten, halten Multiprozessorbetriebssysteme eine dynamische Warteschlange von aktiven Prozessen bereit, die auf ein CPU-Zeitfenster warten.

Obwohl sie es ermöglichen, die CPU-Auslastung deutlich zu verbessern, reicht es nicht aus, sich allein auf Systemaufrufe zu verlassen, um eine zufriedenstellende Umschaltung zwischen den Prozessen zu erzielen. Ein Prozess, der keine Systemaufrufe durchführt, könnte die CPU unbegrenzt steuern. Aus diesem Grund sind moderne Betriebssysteme auch präemptiv, d.h. ein laufender Prozess kann wieder in die Warteschlange zurückgestellt werden, so dass ein wichtigerer Prozess die CPU steuern kann, selbst wenn der laufende Prozess keinen Systemaufruf durchführt.

Der Linux Scheduler

Linux als präemptives Multiprozessorbetriebssystem implementiert einen Scheduler, der die Prozesswarteschlange organisiert. Genauer gesagt, der Scheduler entscheidet, welcher Thread in der Warteschlange ausgeführt wird — ein Prozess kann in viele unabhängige Threads aufgeteilt sein — aber Prozess und Thread sind in diesem Zusammenhang austauschbare Begriffe. Jeder Prozess hat zwei Parameter, die in seine Zeitplanung eingreifen: die Schedulingrichtlinie und die Schedulingpriorität.

Es gibt zwei Haupttypen von Planungsrichtlinien: Echtzeitrichtlinien und normale Richtlinien. Prozesse mit Echtzeitrichtlinien werden direkt anhand ihrer Prioritätswerte geplant. Wenn ein wichtigerer Prozess laufbereit wird, wird einem laufenden aber weniger wichtigen Prozess vorgegriffen und der Prozess mit der höheren Priorität übernimmt die Kontrolle über die CPU. Ein Prozess mit niedrigerer Priorität erlangt nur dann die Kontrolle über die CPU, wenn Prozesse mit höherer Priorität im Leerlauf sind oder auf eine Antwort der Hardware warten.

Jeder Echtzeitprozess hat eine höhere Priorität als ein normaler Prozess. Als Allzweckbetriebssystem führt Linux nur einige wenige Echtzeitprozesse aus. Die meisten Prozesse, einschließlich System- und Benutzerprogramme, laufen unter normalen Schedulingrichtlinien. Normale Prozesse haben für gewöhnlich den gleichen Prioritätswert, aber normale Richtlinien können Regeln für die Ausführungspriorität mit Hilfe eines anderen Prozessparameters definieren: dem nice-Wert. Um Verwirrung mit den dynamischen Prioritäten zu vermeiden, die von nice-Werten abgeleitet werden, werden Schedulingprioritäten gewöhnlich als statische Schedulingprioritäten bezeichnet.

Der Linux Scheduler kann auf viele verschiedene Arten konfiguriert werden, und es gibt noch kompliziertere Möglichkeiten zur Festlegung von Prioritäten, aber diese allgemeinen Konzepte gelten immer. Beim Überprüfen und Abstimmen der Prozessplanung ist es wichtig, sich vor Augen zu halten, dass nur Prozesse unter normalen Schedulingrichtlinien betroffen sind.

Leseprioritäten

Linux reserviert statische Prioritäten von 0 bis 99 für Echtzeitprozesse und normale Prozesse werden statischen Prioritäten von 100 bis 139 zugeordnet, was bedeutet, dass es 40 verschiedene Prioritätsstufen für normale Prozesse gibt. Niedrigere Werte bedeuten höhere Priorität. Die statische Priorität eines aktiven Prozesses können in der sched-Datei gefunden werden, die sich in dem entsprechenden Verzeichnis innerhalb des /proc-Dateisystems befindet:

$ grep ^prio /proc/1/sched
prio                   :       120

Wie im Beispiel gezeigt, gibt die Zeile, welche mit prio beginnt, den Prioritätswert des Prozesses an (der Prozess mit der PID 1 ist der init- oder der systemd-Prozess, der erste Prozess, den der Kernel während der Systeminitialisierung startet). Die Standardpriorität für normale Prozesse beträgt 120, so dass sie auf 100 verringert oder auf 139 erhöht werden kann. Die Prioritäten aller laufenden Prozesse können mit dem Befehl ps -Al oder ps -el überprüft werden:

$ ps -el
F S   UID   PID  PPID  C PRI  NI ADDR SZ WCHAN  TTY          TIME CMD
4 S     0     1     0  0  80   0 -  9292 -      ?        00:00:00 systemd
4 S     0    19     1  0  80   0 -  8817 -      ?        00:00:00 systemd-journal
4 S   104    61     1  0  80   0 - 64097 -      ?        00:00:00 rsyslogd
4 S     0    63     1  0  80   0 -  7244 -      ?        00:00:00 cron
1 S     0   126     1  0  80   0 -  4031 -      ?        00:00:00 dhclient
4 S     0   154     1  0  80   0 -  3937 -      pts/0    00:00:00 agetty
4 S     0   155     1  0  80   0 -  3937 -      pts/1    00:00:00 agetty
4 S     0   156     1  0  80   0 -  3937 -      pts/2    00:00:00 agetty
4 S     0   157     1  0  80   0 -  3937 -      pts/3    00:00:00 agetty
4 S     0   158     1  0  80   0 -  3937 -      console  00:00:00 agetty
4 S     0   160     1  0  80   0 - 16377 -      ?        00:00:00 sshd
4 S     0   280     0  0  80   0 -  5301 -      ?        00:00:00 bash
0 R     0   392   280  0  80   0 -  7221 -      ?        00:00:00 ps

Die Spalte PRI gibt die statische Priorität an, die vom Kernel zugewiesen wird. Beachten Sie jedoch, das sich der von ps angezeigte Prioritätswert von dem im vorherigen Beispiel erhaltenen Wert unterscheidet. Aus historischen Gründen liegen die von ps angezeigten Prioritäten standardmäßig zwischen -40 und 99, so dass sich die tatsächliche Priorität durch Addition von 40 ergibt (in diesem Beispiel: 80 + 40 = 120).

Es ist auch möglich, Prozesse, die derzeit vom Linux-Kernel verwaltet werden, mit dem Programm top kontinuierlich zu überwachen. Wie bei ps wird auch bei top der Prioritätswert anders dargestellt. Um es einfacher zu machen, Echtzeitprozesse zu identifizieren, subtrahiert top den Prioritätswert um 100, wodurch alle Echtzeitprioritäten negativ werden, wobei eine negative Zahl oder rt diese identifiziert. Daher reichen die normalen Prioritäten, die von top angezeigt werden, von 0 bis 39.

Note

Um mehr Details durch den Befehl ps zu erhalten, können zusätzliche Optionen verwendet werden. Vergleichen Sie die Ausgabe dieses Befehls mit der aus unserem vorherigen Beispiel:

$ ps -e -o user,uid,comm,tty,pid,ppid,pri,pmem,pcpu --sort=-pcpu | head

Prozess Niceness

Jeder normale Prozess beginnt mit einem standardisierem nice-Wert von 0 (Priorität 120). Der Name nice (deutch: nett) kommt von der Idee, dass “nettere” Prozesse anderen Prozessen erlauben, vor diesen in der Ausführungswarteschlange zu laufen. Nette Werte reichen von -20 (weniger nett, hohe Priorität) bis 19 (sehr nett, niedrige Priorität). Linux erlaubt auch die Möglichkeit, Threads innerhalb desselben Prozesses verschiedene nice-Werte zuzuweisen. Die Spalte NI in der Ausgabe ps gibt den nice-Wert an.

Nur der Benutzer root kann die Nettigkeit eines Prozesses unter Null senken. Es ist möglich, einen Prozess mit einer nicht standardmäßigen Priorität mit dem Befehl nice zu starten. Standardmäßig ändert nice die Nettigkeit auf 10, dies kann aber mittels der Option -n angepasst werden:

$ nice -n 15 tar czf home_backup.tar.gz /home

In diesem Beispiel wird der Befehl tar mit einer Nettigkeit von 15 gestartet. Der Befehl renice kann verwendet werden, um die Priorität eines laufenden Prozesses zu ändern. Die Option -p bestimmt die PID-Nummer des Zielprozesses. Zum Beispiel:

# renice -10 -p 2164
2164 (process ID) old priority 0, new priority -10

Die Optionen -g und -u werden verwendet, um alle Prozesse einer bestimmten Gruppe bzw. eines bestimmten Benutzers zu modifizieren. Mit renice +5 -g users wird die Nettigkeit der Prozesse, die den Benutzern der Gruppe users angehören, um fünf erhöht.

Neben renice kann die Priorität von Prozessen auch mit anderen Programmen, wie dem Programm top, verändert werden. Auf dem Hauptbildschirm von top kann die Nettigkeit eines Prozesses modifiziert werden, indem man r und dann die PID-Nummer des Prozesses eingibt:

top - 11:55:21 up 23:38,  1 user,  load average: 0,10, 0,04, 0,05
Tasks:  20 total,   1 running,  19 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0,5 us,  0,3 sy,  0,0 ni, 99,0 id,  0,0 wa,  0,2 hi,  0,0 si,  0,0 st
KiB Mem :  4035808 total,   774700 free,  1612600 used,  1648508 buff/cache
KiB Swap:  7999828 total,  7738780 free,   261048 used.  2006688 avail Mem
PID to renice [default pid = 1]
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
    1 root      20   0   74232   7904   6416 S 0,000 0,196   0:00.12 systemd
   15 root      20   0   67436   6144   5568 S 0,000 0,152   0:00.03 systemd-journal
   21 root      20   0   61552   5628   5000 S 0,000 0,139   0:00.01 systemd-logind
   22 message+  20   0   43540   4072   3620 S 0,000 0,101   0:00.03 dbus-daemon
   23 root      20   0   45652   6204   4992 S 0,000 0,154   0:00.06 wickedd-dhcp4
   24 root      20   0   45648   6276   5068 S 0,000 0,156   0:00.06 wickedd-auto4
   25 root      20   0   45648   6272   5060 S 0,000 0,155   0:00.06 wickedd-dhcp6

Die Meldung PID to renice [default pid = 1] erscheint, wobei der erste aufgeführte Prozess standardmäßig ausgewählt ist. Um die Priorität eines anderen Prozesses zu ändern, gibt man dessen PID ein und drückt die Eingabetaste. Dann erscheint die Meldung Renice PID 1 to value (mit der angeforderten PID-Nummer), und es kann ein neuer nice-Wert zugewiesen werden.

Geführte Übungen

  1. Was passiert in einem präemptiven Multitaskingsystem, wenn ein Prozess niedrigerer Priorität den Prozessor belegt und ein Prozess höherer Priorität zur Ausführung in die Warteschlange eingefügt wird?

  2. Betrachten Sie die folgende Ausgabe von top:

    top - 08:43:14 up 23 days, 12:29,  5 users,  load average: 0,13, 0,18, 0,21
    Tasks: 240 total,   2 running, 238 sleeping,   0 stopped,   0 zombie
    %Cpu(s):  1,4 us,  0,4 sy,  0,0 ni, 98,1 id,  0,0 wa,  0,0 hi,  0,0 si,  0,0 st
    MiB Mem :   7726,4 total,    590,9 free,   1600,8 used,   5534,7 buff/cache
    MiB Swap:  30517,0 total,  30462,5 free,     54,5 used.   5769,4 avail Mem
    
      PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
        1 root      20   0  171420  10668   7612 S   0,0   0,1   9:59.15 systemd
        2 root      20   0       0      0      0 S   0,0   0,0   0:02.76 kthreadd
        3 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 rcu_gp
        4 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 rcu_par_gp
        8 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 mm_percpu_wq
        9 root      20   0       0      0      0 S   0,0   0,0   0:49.06 ksoftirqd/0
       10 root      20   0       0      0      0 I   0,0   0,0  18:24.20 rcu_sched
       11 root      20   0       0      0      0 I   0,0   0,0   0:00.00 rcu_bh
       12 root      rt   0       0      0      0 S   0,0   0,0   0:08.17 migration/0
       14 root      20   0       0      0      0 S   0,0   0,0   0:00.00 cpuhp/0
       15 root      20   0       0      0      0 S   0,0   0,0   0:00.00 cpuhp/1
       16 root      rt   0       0      0      0 S   0,0   0,0   0:11.79 migration/1
       17 root      20   0       0      0      0 S   0,0   0,0   0:26.01 ksoftirqd/1

    Welche PIDs haben Echtzeitpriorität?

  3. Betrachten Sie die folgende Auflistung von ps -el:

    F S   UID   PID  PPID  C PRI  NI ADDR SZ WCHAN  TTY          TIME CMD
    4 S     0     1     0  0  80   0 - 42855 -      ?        00:09:59 systemd
    1 S     0     2     0  0  80   0 -     0 -      ?        00:00:02 kthreadd
    1 I     0     3     2  0  60 -20 -     0 -      ?        00:00:00 rcu_gp
    1 S     0     9     2  0  80   0 -     0 -      ?        00:00:49 ksoftirqd/0
    1 I     0    10     2  0  80   0 -     0 -      ?        00:18:26 rcu_sched
    1 I     0    11     2  0  80   0 -     0 -      ?        00:00:00 rcu_bh
    1 S     0    12     2  0 -40   - -     0 -      ?        00:00:08 migration/0
    1 S     0    14     2  0  80   0 -     0 -      ?        00:00:00 cpuhp/0
    5 S     0    15     2  0  80   0 -     0 -      ?        00:00:00 cpuhp/1

    Welche PID hat die höchste Priorität?

  4. Nach dem Versuch, einen Prozess mit renice anzupassen, tritt der folgende Fehler auf:

    $ renice -10 21704
    renice: failed to set priority for 21704 (process ID): Permission denied

    Was ist die wahrscheinliche Ursache für den Fehler?

Offene Übungen

  1. Das Ändern von Prozessprioritäten ist normalerweise erforderlich, wenn ein Prozess zu viel CPU-Zeit beansprucht. Unter Verwendung von ps mit Standardoptionen für die Ausgabe aller Systemprozesse im ausführlichen Format, welches --sort-Flag sortiert die Prozesse nach CPU-Auslastung in aufsteigender Reihenfolge?

  2. Das Kommando schedtool kann alle CPU-Scheduling-Parameter setzen, die Linux beherrscht, oder Informationen für bestimmte Prozesse anzeigen. Wie kann es benutzt werden, um die Planungsparameter des Prozesses 1750 anzuzeigen? Wie kann schedtool benutzt werden, um den Prozess 1750 auf Echtzeit mit Priorität -90 (wie von top angezeigt) umzustellen?

Zusammenfassung

Diese Lektion behandelt, wie Linux die CPU-Zeit unter seinen verwalteten Prozessen aufteilt. Um eine optimale Leistung zu erzielen, müssen kritischere Prozesse weniger kritische Prozesse beiseiteschieben. Die Lektion behandelt folgenden Schritte:

  • Grundlegende Konzepte über Multiprozessorsysteme.

  • Was ist ein Prozessscheduler und wie wird er von Linux implementiert?

  • Was sind Prioritäten unter Linux, nice-Werte und ihr Zweck.

  • Wie man Prozessprioritäten unter Linux liest und interpretiert.

  • Wie man die Priorität eines Prozesses vor und während seiner Ausführung anpasst.

Lösungen zu den geführten Übungen

  1. Was passiert in einem präemptiven Multitaskingsystem, wenn ein Prozess niedrigerer Priorität den Prozessor belegt und ein Prozess höherer Priorität zur Ausführung in die Warteschlange eingefügt wird?

    Der Prozess mit der niedrigeren Priorität pausiert und der Prozess mit der höheren Priorität wird stattdessen ausgeführt.

  2. Betrachten Sie die folgende Ausgabe von top:

    top - 08:43:14 up 23 days, 12:29,  5 users,  load average: 0,13, 0,18, 0,21
    Tasks: 240 total,   2 running, 238 sleeping,   0 stopped,   0 zombie
    %Cpu(s):  1,4 us,  0,4 sy,  0,0 ni, 98,1 id,  0,0 wa,  0,0 hi,  0,0 si,  0,0 st
    MiB Mem :   7726,4 total,    590,9 free,   1600,8 used,   5534,7 buff/cache
    MiB Swap:  30517,0 total,  30462,5 free,     54,5 used.   5769,4 avail Mem
    
      PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
        1 root      20   0  171420  10668   7612 S   0,0   0,1   9:59.15 systemd
        2 root      20   0       0      0      0 S   0,0   0,0   0:02.76 kthreadd
        3 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 rcu_gp
        4 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 rcu_par_gp
        8 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 mm_percpu_wq
        9 root      20   0       0      0      0 S   0,0   0,0   0:49.06 ksoftirqd/0
       10 root      20   0       0      0      0 I   0,0   0,0  18:24.20 rcu_sched
       11 root      20   0       0      0      0 I   0,0   0,0   0:00.00 rcu_bh
       12 root      rt   0       0      0      0 S   0,0   0,0   0:08.17 migration/0
       14 root      20   0       0      0      0 S   0,0   0,0   0:00.00 cpuhp/0
       15 root      20   0       0      0      0 S   0,0   0,0   0:00.00 cpuhp/1
       16 root      rt   0       0      0      0 S   0,0   0,0   0:11.79 migration/1
       17 root      20   0       0      0      0 S   0,0   0,0   0:26.01 ksoftirqd/1

    Welche PIDs haben Echtzeitpriorität?

    Die PIDs 12 und 16.

  3. Betrachten Sie die folgende Auflistung von ps -el:

    F S   UID   PID  PPID  C PRI  NI ADDR SZ WCHAN  TTY          TIME CMD
    4 S     0     1     0  0  80   0 - 42855 -      ?        00:09:59 systemd
    1 S     0     2     0  0  80   0 -     0 -      ?        00:00:02 kthreadd
    1 I     0     3     2  0  60 -20 -     0 -      ?        00:00:00 rcu_gp
    1 S     0     9     2  0  80   0 -     0 -      ?        00:00:49 ksoftirqd/0
    1 I     0    10     2  0  80   0 -     0 -      ?        00:18:26 rcu_sched
    1 I     0    11     2  0  80   0 -     0 -      ?        00:00:00 rcu_bh
    1 S     0    12     2  0 -40   - -     0 -      ?        00:00:08 migration/0
    1 S     0    14     2  0  80   0 -     0 -      ?        00:00:00 cpuhp/0
    5 S     0    15     2  0  80   0 -     0 -      ?        00:00:00 cpuhp/1

    Welche PID hat die höchste Priorität?

    PID 12.

  4. Nach dem Versuch, einen Prozess mit renice anzupassen, tritt der folgende Fehler auf:

    $ renice -10 21704
    renice: failed to set priority for 21704 (process ID): Permission denied

    Was ist die wahrscheinliche Ursache für den Fehler?

    Nur der Benutzer root kann den nice-Wert unter Null senken.

Lösungen zu den offenen Übungen

  1. Das Ändern von Prozessprioritäten ist normalerweise erforderlich, wenn ein Prozess zu viel CPU-Zeit beansprucht. Unter Verwendung von ps mit Standardoptionen für die Ausgabe aller Systemprozesse im ausführlichen Format, welches --sort-Flag sortiert die Prozesse nach CPU-Auslastung in aufsteigender Reihenfolge?

    $ ps -el --sort=pcpu
  2. Das Kommando schedtool kann alle CPU-Scheduling-Parameter setzen, die Linux beherrscht, oder Informationen für bestimmte Prozesse anzeigen. Wie kann es benutzt werden, um die Planungsparameter des Prozesses 1750 anzuzeigen? Wie kann schedtool benutzt werden, um den Prozess 1750 auf Echtzeit mit Priorität -90 (wie von top angezeigt) umzustellen?

    $ schedtool 1750
    $ schedtool -R -p 89 1750

Linux Professional Insitute Inc. Alle Rechte vorbehalten. Besuchen Sie die LPI Learning Website: https://learning.lpi.org
Dieses Werk steht unter der Lizenz Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International.

Nächste Lektion

103.7 Textdateien mit regulären Ausdrücken durchsuchen (103.7 Lektion 1)

Nächste Lektion lesen

Linux Professional Insitute Inc. Alle Rechte vorbehalten. Besuchen Sie die LPI Learning Website: https://learning.lpi.org
Dieses Werk steht unter der Lizenz Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International.

LPI ist eine Non-Profit-Organisation.

© 2023 Linux Professional Institute (LPI) ist eine globale Organisation für Zertifizierungsstandards und zur Karriereplanung für Open-Source-Profis. Mit mehr als 200.000 Zertifikatsinhabern ist es die weltweit erste und größte herstellerneutrale Linux- und Open-Source-Zertifizierungsstelle. LPI verfügt über zertifizierte Fachleute in über 180 Ländern, bietet Prüfungen in mehreren Sprachen an und hat Hunderte von Trainingspartnern.

Unser Ziel ist es, wirtschaftliche und kreative Möglichkeiten für alle zu ermöglichen, indem wir Open-Source-Wissens- und Kompetenzzertifizierungen allgemein zugänglich machen.

  • LinkedIn
  • flogo-RGB-HEX-Blk-58 Facebook
  • Twitter
  • Kontaktieren Sie uns
  • Datenschutz und Cookie-Richtlinien

Haben Sie einen Fehler entdeckt oder möchten Sie helfen, diese Seite zu verbessern? Lassen Sie es uns wissen.

© 1999–2023 The Linux Professional Institute Inc. Alle Rechte vorbehalten.