1 | memlog - A Memory-Allocation Logging Tool |
---|
2 | |
---|
3 | This tool attempts to help you answer the question: |
---|
4 | Why is my application using so much memory? |
---|
5 | |
---|
6 | ** LINKING ** |
---|
7 | |
---|
8 | How to use it depends on how your application is linked: |
---|
9 | |
---|
10 | For dynamically-linked applications, you can: |
---|
11 | |
---|
12 | 1. Use LD_PRELOAD: Set LD_PRELOAD=/path/to/memlog/libmemlog.so when you run |
---|
13 | your application. |
---|
14 | |
---|
15 | 2. Link directly: Add the following to your linker flags: |
---|
16 | -L/path/to/memlog -Wl,-rpath,/path/to/memlog -lmemlog |
---|
17 | |
---|
18 | For statically-linked applications, add the following to your linker flags: |
---|
19 | |
---|
20 | -Wl,--wrap,malloc,--wrap,free,--wrap,realloc,--wrap,calloc,--wrap,memalign \ |
---|
21 | /path/to/memlog/memlog_s.o -lpthread -ldl |
---|
22 | |
---|
23 | ** RUNNING ** |
---|
24 | |
---|
25 | When your application runs, you should find in your current directory files |
---|
26 | named 'HOST.PID.memlog', one for each process. These contain the raw tracing |
---|
27 | information, and are only somewhat human readable. You can create a ps/pdf |
---|
28 | file detailing the memory allocated when each process reached its peak memory |
---|
29 | use by running: |
---|
30 | |
---|
31 | /path/to/memlog/memlog2dot /path/to/HOST.PID.memlog |
---|
32 | |
---|
33 | this will generate files named HOST.PID.memlog.dot, HOST.PID.memlog.ps and |
---|
34 | HOST.PID.memlog.pdf. You'll probably find the pdf file most convenient for |
---|
35 | viewing. HOST.PID.memlog.txt is also generated, providing the same information |
---|
36 | in textual form. |
---|
37 | |
---|
38 | Note that te peak memory usage is determined by monitoring the processes's |
---|
39 | maximum resident set size, not just the total allocated heap memory. |
---|
40 | |
---|
41 | memlog2dot depends on dot (from the graphviz package) and ps2pdf (from the |
---|
42 | ghostscript package), plus various tools from the binutils package. |
---|
43 | |
---|
44 | ** RELATED WORK ** |
---|
45 | |
---|
46 | Why was memlog created? There are several other tools that can support this use |
---|
47 | case, but none of them would work in our environment properly. They were |
---|
48 | either too slow, not runnable under the BG/Q CNK, not thread safe, did not |
---|
49 | properly support big-endian PPC64, supported only either static or dynamic |
---|
50 | linking, did not collect full backtraces, or just did not produce |
---|
51 | sufficiently-informative peak-usage output. |
---|
52 | |
---|
53 | That having been said, some other tools that might interest you: |
---|
54 | Valgrind Massif - http://valgrind.org/docs/manual/ms-manual.html |
---|
55 | Google Performance Tools - http://google-perftools.googlecode.com/svn/trunk/doc/heapprofile.html |
---|
56 | memtrail - https://github.com/jrfonseca/memtrail |
---|
57 | LeakTracer - http://www.andreasen.org/LeakTracer/ |
---|
58 | glibc mtrace - http://www.gnu.org/s/hello/manual/libc/Allocation-Debugging.html |
---|
59 | Heaptrack - http://milianw.de/blog/heaptrack-a-heap-memory-profiler-for-linux |
---|
60 | MemProf - http://www.secretlabs.de/projects/memprof/ |
---|
61 | |
---|
62 | The dot/pdf output produced by memlog was definitely inspired by that produced |
---|
63 | by Google's pprof tool in the aforementioned package. |
---|
64 | |
---|