blob: 572c0dceb94e09472965bd83dfea50342c52b216 [file] [log] [blame]
.TH drsnoop 8 "2019-02-20" "USER COMMANDS"
.SH NAME
drsnoop \- Trace direct reclaim events. Uses Linux eBPF/bcc.
.SH SYNOPSIS
.B drsnoop.py [\-h] [\-T] [\-U] [\-p PID] [\-t TID] [\-u UID] [\-d DURATION] [-n name] [-v]
.SH DESCRIPTION
drsnoop trace direct reclaim events, showing which processes are allocing pages
with direct reclaiming. This can be useful for discovering when allocstall (/p-
roc/vmstat) continues to increase, whether it is caused by some critical proc-
esses or not.
This works by tracing the direct reclaim events using kernel tracepoints.
This makes use of a Linux 4.4 feature (bpf_perf_event_output());
for kernels older than 4.4, see the version under tools/old,
which uses an older mechanism.
Since this uses BPF, only the root user can use this tool.
.SH REQUIREMENTS
CONFIG_BPF and bcc.
.SH OPTIONS
.TP
\-h
Print usage message.
.TP
\-T
Include a timestamp column.
.TP
\-U
Show UID.
.TP
\-p PID
Trace this process ID only (filtered in-kernel).
.TP
\-t TID
Trace this thread ID only (filtered in-kernel).
.TP
\-u UID
Trace this UID only (filtered in-kernel).
.TP
\-d DURATION
Total duration of trace in seconds.
.TP
\-n name
Only print processes where its name partially matches 'name'
\-v verbose
Run in verbose mode. Will output system memory state
.SH EXAMPLES
.TP
Trace all direct reclaim events:
#
.B drsnoop
.TP
Trace all direct reclaim events, for 10 seconds only:
#
.B drsnoop -d 10
.TP
Trace all direct reclaim events, and include timestamps:
#
.B drsnoop \-T
.TP
Show UID:
#
.B drsnoop \-U
.TP
Trace PID 181 only:
#
.B drsnoop \-p 181
.TP
Trace UID 1000 only:
#
.B drsnoop \-u 1000
.TP
Trace all direct reclaim events from processes where its name partially match-
es 'mond':
#
.B drnsnoop \-n mond
.SH FIELDS
.TP
TIME(s)
Time of the call, in seconds.
.TP
UID
User ID
.TP
PID
Process ID
.TP
TID
Thread ID
.TP
COMM
Process name
.SH OVERHEAD
This traces the kernel direct reclaim tracepoints and prints output for each
event. As the rate of this is generally expected to be low (< 1000/s), the
overhead is also expected to be negligible.
.SH SOURCE
This is from bcc.
.IP
https://github.com/iovisor/bcc
.PP
Also look in the bcc distribution for a companion _examples.txt file containing
example usage, output, and commentary for this tool.
.SH OS
Linux
.SH STABILITY
Unstable - in development.
.SH AUTHOR
Wenbo Zhang