ps ax
Dies ist eine alte Version des Dokuments!
Inhaltsverzeichnis
Prozessverwaltung
Prozesse anzeigen
ps
Status
Anzeigen aller Prozesse, incl. Benutzer: 3)
ps -elf
Anzeige alle sortiert:
ps -e --sort rsz
Anzeige ausgewählter Felder sortiert:
ps -eo cmd,uname,rsz,cputime,%cpu,state --sort rsz
Anzeige ausgewählter Prozesse und ausgewählter Felder sortiert:
ps -C gzip,bzip2 -o cmd,uname,rsz,cputime,%cpu,state --sort rsz
Mit dem BSD Befehlssatz Alle Prozess, mit User und MEM/CPU-Statistik, als Wide (volle Kommandozeile) und als Baum (f)
ps ax ps aux ps auxw ps auxwf
Anzeige aller Prozesse incl. cgroup:
alias psc='ps xawf -eo pid,user,cgroup,args' psc
pgrep, lsof, pstree, top
Anzeige aller zip Prozesse:
pgrep -l zip
Anzeigen, welche Dateien ein Prozess geöffnet hat:
lsof -p 4711
oder
lsof -c update-notifier
Prozesse baumartig darstellen:
pstree pstree -p pstree -up
Prozessbau der eigenen Shell (long)
pstree -pul -s $$
Prozesse nach Ressourcenverbrauch sortiert anzeigen:
top
Modernere Variante von top:
htop
Prozess Prioritäten
Priorität anzeigen
nice
oder
ps -p $$ -o pid,nice,cmd
Prozess mit um 5 abgesenkter Priorität starten:
nice -5 bash
Priorität eines laufenden Prozesses auf 3 ändern:
renice 3
Signale
Prozess normal beenden, Daten werden gepeichert:
kill 4711 kill -TERM 4711
Prozess sofort beenden, ohne speichern:
kill -KILL 4711 kill -9 4711
Prozess bitten, die Konfigurationsdatei neu einzulesen 4):
kill -HUP 4711
aktuelle Shell informieren, daß sich die Fenstergröße geändert hat
kill -WINCH $$
Signal für aktuelle Shell umdefinieren:
trap 'echo bäah!' TERM kill -TERM $$
Alle zip-Prozesse beenden:
pkill zip
Beispiel: Zombie erzeugen
sleep 30 & exec sleep 200
Wieviel Speicher ist noch frei?
free -m
total used free shared buffers cached Mem: 503 296 206 0 26 102 -/+ buffers/cache: 167 336 Swap: 1592 0 1592
Hier das ganze mal beschriftet, damit klar ist, wovon ich unten rede:
free -m
total used free shared buffers cached Mem: (1) (2) (3) (4) (5) (6) -/+ buffers/cache: (7) (8) Swap: (9) (10) (11)
- Die physikalische Menge flüchtigen Speichers, abzüglich dessen, was für den Kernel und dessen Datenstrukturen draufgeht.
- Der benutzte Speicher, also alles, was für Programme, deren Libraries, Datenhaltung draufgeht. Außerdem der Buffer- und der Pagecache.
- Unbenutzter Speicher. Niemand hat dort Dinge abgelegt. Der Speicher kann direkt benutzt werden, wenn man welchen braucht. Wobei er u. U. natürlich initialisiert werden sollte
- Der durch Shared Memory belegte Speicher.
- Der durch den Buffer-Cache belegte Speicher
- Der durch den Page Cache belegte Speicher
- Der belegte Speicher von (2) abzüglich der Summe aus (5) und (6)
- Der freie Speicher von (3) plus der Summe aus (5) und (6)
- Die gesamte Menge an Swapspace, die zur Verfügung steht.
- Der belegte Swapspace
- Der noch freie Swapspace, also (9) abzüglich (10)
Das bedeutet also, dass im Falle ganz oben insgesamt 167M von Programmen und ähnlichem belegt ist und ich theoretisch 336M zusätzliche belegen könnte. Dann wäre aber der PageCache auf 0 und der Buffer Cache ebenfalls. Da das sehr auf die Performance ginge, würde der Kernel vorher bereits einige Programme, die selten laufen (z. B. ein unbeschäftigter exim oder irgendwelche anderen Daemons, die selten laufen) in den Swap verschieben. Zum schnellen Überblick, wie viel Speicher denn noch frei ist (also eigentlich, wie viel Speicher denn noch nutzbar ist), ist die Zahl unter (8) am besten als Indikator zu gebrauchen.
Beispiel: Cache füllen
In einem Fenster Speicher beobachten:
watch free -m
Im zweiten Fenster unsinnig Dateien lesen:
grep -r lakdsjf /usr/ 2>/dev/null >/dev/null
Beispiel: Cache leeren
In einem Fenster Speicher beobachten:
watch free -m
Im zweiten Fenster ein Programm viel Speicher verbrauchen lassen:
dd bs=1M count=1500 < /dev/zero | sort > /dev/null
Oder einfach:
echo 3 > /proc/sys/vm/drop_caches
Beispiel: Speicher füllen
Prozess starten, der 2000MB verbraucht:
dd if=/dev/zero bs=1M count=2000 | perl -e '$slurp=<>; sleep'
oder
dd if=/dev/zero bs=1M count=2000 | read slurp
man waitpid: A child that terminates, but has not been waited for becomes a „zombie“. The kernel maintains a minimal set of information about the zombie process (PID, termination status, resource usage information) in order to allow the parent to later perform a wait to obtain information about the child. As long as a zombie is not removed from the system via a wait, it will consume a slot in the kernel process table, and if this table fills, it will not be possible to create further processes. If a parent process terminates, then its „zombie“ children (if any) are adopted by init(1), (or by the nearest „subreaper“ process …; init(1) automatically performs a wait to remove the zombies.ps aux

