forked from iovisor/bcc
/
slabratetop_example.txt
134 lines (115 loc) · 5.22 KB
/
slabratetop_example.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
Demonstrations of slabratetop, the Linux eBPF/bcc version.
slabratetop shows the rate of allocations and total bytes from the kernel
memory allocation caches (SLAB or SLUB), in a top-like display that refreshes.
For example:
# ./slabratetop
<screen clears>
07:01:35 loadavg: 0.38 0.21 0.12 1/342 13297
CACHE ALLOCS BYTES
kmalloc-4096 3554 14557184
kmalloc-256 2382 609536
cred_jar 2568 493056
anon_vma_chain 2007 128448
anon_vma 972 77760
sighand_cache 24 50688
mm_struct 49 50176
RAW 52 49920
proc_inode_cache 59 38232
signal_cache 24 26112
dentry 135 25920
sock_inode_cache 29 18560
files_cache 24 16896
inode_cache 13 7696
TCP 2 3840
pid 24 3072
sigqueue 17 2720
ext4_inode_cache 2 2160
buffer_head 16 1664
xfs_trans 5 1160
By default the screen refreshes every one second, and only the top 20 caches
are shown. These can be tuned with options: see USAGE (-h).
The output above showed that the kmalloc-4096 cache allocated the most, about
14 Mbytes during this interval. This is a generic cache; other caches have
more meaningful names ("dentry", "TCP", "pid", etc).
slabtop(1) is a similar tool that shows the current static volume and usage
of the caches. slabratetop shows the active call rates and total size of the
allocations.
Since "kmalloc-4096" isn't very descriptive, I'm interested in seeing the
kernel stacks that led to this allocation. In the future (maybe by now) the
bcc trace tool could do this. As I'm writing this, it can't, so I'll use my
older ftrace-based kprobe tool as a workarond. This is from my perf-tools
collection: https://github.com/brendangregg/perf-tools.
# ./perf-tools/bin/kprobe -s 'p:kmem_cache_alloc name=+0(+96(%di)):string' 'name == "kmalloc-4096' | head -100
Tracing kprobe kmem_cache_alloc. Ctrl-C to end.
kprobe-3892 [002] d... 7888274.478331: kmem_cache_alloc: (kmem_cache_alloc+0x0/0x1b0) name="kmalloc-4096"
kprobe-3892 [002] d... 7888274.478333: <stack trace>
=> kmem_cache_alloc
=> user_path_at_empty
=> vfs_fstatat
=> SYSC_newstat
=> SyS_newstat
=> entry_SYSCALL_64_fastpath
kprobe-3892 [002] d... 7888274.478340: kmem_cache_alloc: (kmem_cache_alloc+0x0/0x1b0) name="kmalloc-4096"
kprobe-3892 [002] d... 7888274.478341: <stack trace>
=> kmem_cache_alloc
=> user_path_at_empty
=> vfs_fstatat
=> SYSC_newstat
=> SyS_newstat
=> entry_SYSCALL_64_fastpath
kprobe-3892 [002] d... 7888274.478345: kmem_cache_alloc: (kmem_cache_alloc+0x0/0x1b0) name="kmalloc-4096"
kprobe-3892 [002] d... 7888274.478346: <stack trace>
=> kmem_cache_alloc
=> user_path_at_empty
=> vfs_fstatat
=> SYSC_newstat
=> SyS_newstat
=> entry_SYSCALL_64_fastpath
kprobe-3892 [002] d... 7888274.478350: kmem_cache_alloc: (kmem_cache_alloc+0x0/0x1b0) name="kmalloc-4096"
kprobe-3892 [002] d... 7888274.478351: <stack trace>
=> kmem_cache_alloc
=> user_path_at_empty
=> vfs_fstatat
=> SYSC_newstat
=> SyS_newstat
=> entry_SYSCALL_64_fastpath
kprobe-3892 [002] d... 7888274.478355: kmem_cache_alloc: (kmem_cache_alloc+0x0/0x1b0) name="kmalloc-4096"
kprobe-3892 [002] d... 7888274.478355: <stack trace>
=> kmem_cache_alloc
=> user_path_at_empty
=> vfs_fstatat
=> SYSC_newstat
=> SyS_newstat
=> entry_SYSCALL_64_fastpath
kprobe-3892 [002] d... 7888274.478359: kmem_cache_alloc: (kmem_cache_alloc+0x0/0x1b0) name="kmalloc-4096"
kprobe-3892 [002] d... 7888274.478359: <stack trace>
=> kmem_cache_alloc
=> user_path_at_empty
=> vfs_fstatat
=> SYSC_newstat
=> SyS_newstat
=> entry_SYSCALL_64_fastpath
[...]
This is just an example so that you can see it's possible to dig further.
Please don't copy-n-paste that kprobe command, as it's unlikely to work (the
"+0(+96(%di))" text is specific to a kernel version and architecture).
So these allocations are coming from user_path_at_empty(), which calls other
functions (not seen in the stack: I suspect it's a tail-call compiler
optimization).
USAGE:
# ./slabratetop -h
usage: slabratetop [-h] [-C] [-r MAXROWS] [interval] [count]
Kernel SLAB/SLUB memory cache allocation rate top
positional arguments:
interval output interval, in seconds
count number of outputs
optional arguments:
-h, --help show this help message and exit
-C, --noclear don't clear the screen
-r MAXROWS, --maxrows MAXROWS
maximum rows to print, default 20
examples:
./slabratetop # kmem_cache_alloc() top, 1 second refresh
./slabratetop -C # don't clear the screen
./slabratetop 5 # 5 second summaries
./slabratetop 5 10 # 5 second summaries, 10 times only