Differences between version 15 and revision by previous author of ProcessNotes.
Other diffs: Previous Major Revision, Previous Revision, or view the Annotated Edit History
| Newer page: | version 15 | Last edited on Tuesday, April 6, 2004 2:31:07 am | by AristotlePagaltzis | Revert |
| Older page: | version 13 | Last edited on Sunday, November 17, 2002 10:40:21 pm | by CraigBox | Revert |
@@ -1,43 +1,32 @@
-Useful Process Related utilities
+!!
Useful Process Related utilities
-ps(1) - display process status
%%%
-pstree
(1
) - display a tree of
processes %%%
-top(1) - display the top cpu processes
%%%
--
Send a signal(7)
to a process by ProcessID %%%
--
Send a signal(7)
to a process by name %%%
--
Send a signal(7)
to all running processes%%%
-nice(1) -run
a program with modified scheduling priority%%%
-pidof(8) - Tells you the
pid(s) of a
process by name%%%
-fuser
(8
) - Tells you which
processes are using
a resource, and optionally send them a signal(7)
%%%
-lsof
(8
) - Similar to fuser
-vmstat(8) - get vm
statistics and information.
+;
%%% fuser
(8
) : Tells you which
processes are using a resource, and optionally send them a [Signal]
+;
%%% kill(1) :
Send a [Signal]
to a process by ProcessID
+;
%%% killall(1) :
Send a [Signal]
to a process by name
+;
%%% killall5(8) :
Send a [Signal]
to all running processes
+;
%%% lsof(8) : Similar to fuser(8)
+; %%%
nice(1) : Run
a program with modified scheduling priority
+;
%%% pgrep(1), pkill(1) : Look up or signal processes based on name and other attributes
+; %%%
pidof(8) : List
pid(s) of process(es)
by name
+;
%%% ps(1) : Display process status
+; %%% pstree
(1
) : Display
processes as
a tree
+;
%%% top
(1) : Display processes sorted by certain criteria (default: [CPU] load
)
+; %%%
vmstat(8) : Show VirtualMemory
statistics
-Oi! You were supposed to discuss these utilities too. Like what sets of arguments to ps are the most useful, how to display arguments to commands in top. what RSS is, how this interacts with ulimit(3).
+----
-''I'm going to, these things take time ;) -- CraigMckenna ''
-''time?
! It's been months and you've not updated this page :P Bah, now I'm going to have to do it :P -- PerryLorier''
+!! top
-----
The 'TIME' column in top is the amount of time the program has spent running, not to be confused that the amount of time since the program was started. eg: a program started a month ago may have only run for 1 minute total, so it's TIME column will only show 1 minute of running time.
-----
+
RSS is the ResidentSetSize, the amount of memory that the program has which is actually *in* memory (not swapped out). Note that this also covers memory which is shared between programs and threads. Mozilla for instance shows as using about 20M in 5 processes, but this doesn't mean it is using 100M in total, it means it's using about 20M in total, shared between 5 processes :)
-----
+
Someone was searching for "WCHAN", so here's a definition, when a process is 'sleeping in the kernel' (in the S state) then WCHAN is the function inside the kernel it is sleeping on. for instance init(8) (at least on my machine) usually is blocked inside "select" from select(2).
-----
-nice(1) lets you make programs "nicer" (ie: have less access to the [CPU] in proportion to other processes). nice values in Linux range between -20 and +19. The default nice(1) level is "". Only the root user can lower their niceless level. Higher nice level means it has a lower priority. A process running at -20 is considered "RealTime" and is never preempted.
- nice -n ''nicelevelchange'' ''program'
-eg:
- nice -n 1 ./program OR nice -1 ./program
-will run ./program with one level higher niceness (ie: *lower* priority compared to other processes).
-
- nice --5 ./program
-will run a process with lower niceness (ie *higher* priority) of negative 5. (Only the root user can do this).
-----
-%%%
+top(1)'s summary output:
* The top line has the uptime, the number of users logged in (according to utmp(5)) and the LoadAverage (according to uptime(1))
-* The next line has the number of processes, then a break down of sleeping processes (processes blocked waiting for an event), the number of running processes, the number of zombie processes
(processes that haven't been cleaned up by their parent process) and the number of stopped processes (processes that are stopped by SIGSTOP)
+* The next line has the number of processes, then a break down of sleeping processes (processes blocked waiting for an event), the number of running processes, the number of [ZombieProcess]es
(processes that haven't been cleaned up by their parent process) and the number of stopped processes (processes that are stopped by SIGSTOP)
* The next line has the CPU states, amount used in userspace, the amount of CPU used in the system (kernel and device drivers), the number of cpu used by nice processes (processes that have a lower than normal priority) and the amount of cpu time that is idle (is spent with the cpu shutdown)
* Then the memory breakdowns:
** Total amount of physical memory that the kernel knows about
** The amount of physical memory that is in use
@@ -47,46 +36,104 @@
** Total amount of swap space
** Total amount of swap used
** Total amount of swap free
** Total amount of physical memory being used as disk cache.
-After this comes the list of processes
+
+
After this comes the list of processes.
Some hints:
* If you're doing a lot of I/O (or especially older IDE I/O) you will probably see your "System %" increase. This means that your CPU is spending it's time talking to the hardware, and perhaps not spending much time doing whatever you want it to. If your system % is high you should perhaps consider upgrading your hardware.
* If the number of zombies is high then you possibly have a poorly written program that doesn't cleanup zombies. use pstree(1) to get an idea which process is not cleaning up it's children.
* See LoadAverage about the Load average and related issues.
-----
The various states of a process can be:
|^ __State__ |^ __Meaning__
| S | Sleeping
| W | Swapped out
| R | Running
| D | Blocked in a device driver in the kernel. Unkillable.
| < | Process is running with a high priority (nice level <0)
+
----
-also, in a related note, if you want to grep for a running process (eg foo) use:
- ps ax | grep "[[f]oo"
-not:
- ps ax | grep "foo"
-the reason for this
is that the latter example will also find the
"foo
" in the grep command line, where as
the first one
can't
.
+!! nice
+
+nice(1) lets you make programs "nicer" (ie: have less access to
the [CPU] in proportion to other processes). nice values in Linux range between -20 and +19. The default nice(1) level
is "
". Only
the root user
can lower their niceless level. Higher nice level means it has a lower priority. A process running at -20 is considered "RealTime" and is never preempted.
+
+ nice -n
''nicelevelchange'' ''program'
+
+eg:
+
+ nice -n 1 ./program OR nice -1 ./program
+
+will run ./program with one level higher niceness (ie: *lower* priority compared to other processes).
+
+ nice --5 ./program
+
+will run a process with lower niceness (ie *higher* priority) of negative 5. (Only the root user can do this)
.
+
----
-poor mans "
ps"
(for when ps(1) just don't work or can't be relied upon):
- cd /proc;
for i
in *; do if
[[ -r $i/cmdline
]; then
echo -n
${i}:; xargs -
0 -n 1 echo -n "
" <$i
/cmdline;
echo; fi; done
----
-
-if your program says "Segmentation fault" (or similar), then you can retrieve information about the process when it crashed. first type
- ulimit
-c unlimited
-this removes the limit on dumping core files (so it should dump core now), see builtins(1) and ulimit(3) for more information about this. then run the program again. this time when it says "Segmentation fault" it will leave a file called "core" which contains the state of the program when it died. this file can be inspected by gdb
''programname'' ''corefilename''. To find out where it crashed try "bt full" at the prompt. you can also print variables to find out what they currently hold, for example "print argc" will tell you the contents of argc. of course, "quit" or C
-d will exit gdb. For more information about the gnu debugger see gdb(1). For more information about this see DeBugging
-----
- ps -auxww
-is probably the most useful ps(1) command imho
+
+!! ps
+
+If you want to grep for a running process (eg foo) use:
+
+ ps ax | grep [[f]oo
+
+not:
+
+ ps ax | grep foo
+
+The reason for this is that the latter example will also find the __grep foo__ itself in the process list, while the first one won't.
+
+The most useful ps(1) command is probably
+
+ ps auxww
+
+This gives a lot more information about each process than you get by default.
+
+Here is a
poor man's Linux-only
ps replacement
(for when ps(1) just don't work
+
or can't be relied upon):
+
+ #!/bin/bash
+ cd /proc &&
for p
in [[
-9
]*
; do
+
echo -ne "
$p\
"
+ tr '\' ' '
< $p
/cmdline
+
echo -ne '\'
+ done | xargs
-r0t printf
' %5g %s\n
' | sort
-ns
----
-if
you want to unmount a filesystem but its
in use you can use
+!! Miscellaneous
+
+If
you want to unmount a filesystem but it's
in use you can use
ps -auxwwe |grep ''mountpoint''
lsof | grep ''mountpoint''
fuser -vm ''mountpoint''
lsof(8) stands for __l__i__s__t of __o__pen __f__iles.
+
+PerryLorier suggests
+
+ fuser -k -v -m /mnt/nfs
+
+to kill all processes using that mount point.
+
+If your program says "[Signal] 11", "SegmentationFault", or similar, you can
+retrieve information about the process when it crashed. First remove the limit
+on dumping core files (so it will dump core this time around):
+
+ ulimit -c unlimited
+
+Then run the program again. (See builtins(1) and ulimit(3) for more information
+about this.) This time when it [SegmentationFault]s it will leave a file called
+"core" which contains the state of the program when it died. This file can be
+inspected by
+
+ gdb ''programname'' ''corefilename''
+
+To find out where it crashed try __bt full__ at the prompt. You can also print
+variables to find out what they currently hold, for example __print argc__ will
+tell you the contents of argc. Of course, __quit__ or [[Ctrl][[d] will exit
+gdb. For more information about the [GNU] debugger see gdb(1). For more
+information about this procedure see DeBugging.
