1uobjnew(8) System Manager's Manual uobjnew(8)
2
3
4
6 uobjnew, javaobjnew, rubyobjnew, cobjnew - Summarize object allocations
7 in high-level languages.
8
10 javaobjnew [-h] [-C TOP_COUNT] [-S TOP_SIZE] [-v] pid [interval]
11 rubyobjnew [-h] [-C TOP_COUNT] [-S TOP_SIZE] [-v] pid [interval]
12 cobjnew [-h] [-C TOP_COUNT] [-S TOP_SIZE] [-v] pid [interval]
13 uobjnew [-h] [-C TOP_COUNT] [-S TOP_SIZE] [-v] [-l {java,ruby,c}] pid
14 [interval]
15
17 uobjnew traces object allocations in high-level languages (including
18 "malloc") and prints summaries of the most frequently allocated types
19 by number of objects or number of bytes.
20
21 This tool relies on USDT probes embedded in many high-level languages,
22 such as Node, Java, Python, and Ruby. It requires a runtime instru‐
23 mented with these probes, which in some cases requires building from
24 source with a USDT-specific flag, such as "--enable-dtrace" or "--with-
25 dtrace". For Java, the Java process must be started with the
26 "-XX:+ExtendedDTraceProbes" flag.
27
28 Since this uses BPF, only the root user can use this tool.
29
31 CONFIG_BPF and bcc.
32
34 -C TOP_COUNT
35 Print the top object types sorted by number of instances.
36
37 -S TOP_SIZE
38 Print the top object types sorted by size.
39
40 -v Print the resulting BPF program, for debugging purposes.
41
42 {java,ruby,c}
43 The language to trace.
44
45 pid The process id to trace.
46
47 interval
48 Wait this many seconds and then print the summary and exit. By
49 default, wait for Ctrl+C to exit.
50
52 Trace object allocations in a Ruby process:
53 # uobjnew ruby 148
54
55 Trace object allocations from "malloc" and print the top 10 by total
56 size:
57 # uobjnew -S 10 c 1788
58
60 TYPE The object type being allocated. For C (malloc), this is the
61 block size.
62
63 ALLOCS The number of objects allocated.
64
65 BYTES The number of bytes allocated.
66
68 Object allocation events are quite frequent, and therefore the overhead
69 from running this tool can be considerable. Use with caution and make
70 sure to test before using in a production environment. Nonetheless,
71 even thousands of allocations per second will likely produce a reason‐
72 able overhead when investigating a problem.
73
75 This is from bcc.
76
77 https://github.com/iovisor/bcc
78
79 Also look in the bcc distribution for a companion _example.txt file
80 containing example usage, output, and commentary for this tool.
81
83 Linux
84
86 Unstable - in development.
87
89 Sasha Goldshtein
90
92 ustat(8), ugc(8), memleak(8)
93
94
95
96USER COMMANDS 2016-11-07 uobjnew(8)