使用valgrind跟踪管道命令的内存使用情况

我有几个进程正在运行我写的管道连接的工具，我想用valgrind来衡量他们收集的内存使用情况。到目前为止，我已经试过类似：使用valgrind跟踪管道命令的内存使用情况

$ valgrind tool=massif trace-children=yes --peak-inaccuracy=0.5 --pages-as-heap=yes --massif-out-file=myProcesses".%p" myProcesses.script

凡myProcesses.script运行我的工具foo相当于两次，例如：

foo | foo > /dev/null

Valgrind的似乎并没有捕捉到这个我所期望的方式收集到的内存使用情况。如果我使用top来跟踪这个，我得到（出于参数的缘故）第一个foo上10％的内存使用率，然后另一个10％在myProcesses.script完成之前收集第二个foo。这是我想衡量的事情：这两个过程的使用。 Valgrind的，而不是返回以下错误：

Massif: ms_main.c:1891 (ms_new_mem_brk): Assertion 'VG_IS_PAGE_ALIGNED(len)' failed.

有没有办法来收集我使用的管道方式的命令内存使用情况数据（使用valgrind）？或者我可以使用一个类似的工具来准确自动执行这些测量？

top在轮询时返回的数字对我来说似乎是手动的，我正在寻求准确和可重复的测量。如果您有替代工具的建议，我也欢迎这些。

编辑 - 固定错字valgrind选项。

编辑2 - 出于某种原因，看起来选项--pages-as-heap给我们带来了我们正在测试的二进制文件的麻烦。你的例子运行良好。每次我们输入非内联函数时都会创建一个新页面（堆栈溢出 - heh）。我们想要对这些数据进行计数，但它们在我们测试的内存使用规模上相对较小。（也许ls或less中没有函数调用？）删除--pages-as-heap有助于再次进行测试。感谢MrGomez的大力帮助。

来源

2012-03-22 Alex Reynolds

至于你的页面对齐问题，这显然与在地块中设置新的内存断点时分页行为失败有关。我无法在我的结尾重现这个问题，但是我推测'--pages-as-heap = yes'在你的系统调用的上下文中对此负责。很显然，如果你想探究错误情况，看看为什么在调试器中碰到这种情况是最好的方法。（请参阅下面的答案。） – MrGomez 2012-03-24 23:03:28

使用错误中给出的正确的valgrind版本，这似乎只适用于我在Valgrind 3.6.1。我调用：

<me>@harley:/tmp/test$ /usr/local/bin/valgrind --tool=massif \ 
    --trace-children=yes --peak-inaccuracy=0.5 --pages-as-heap=yes \ 
    --massif-out-file=myProcesses".%p" ./testscript.sh 
==21067== Massif, a heap profiler 
==21067== Copyright (C) 2003-2010, and GNU GPL'd, by Nicholas Nethercote 
==21067== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info 
==21067== Command: ./testscript.sh 
==21067== 
==21068== Massif, a heap profiler 
==21068== Copyright (C) 2003-2010, and GNU GPL'd, by Nicholas Nethercote 
==21068== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info 
==21068== Command: /bin/ls 
==21068== 
==21070== Massif, a heap profiler 
==21070== Copyright (C) 2003-2010, and GNU GPL'd, by Nicholas Nethercote 
==21070== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info 
==21069== Massif, a heap profiler 
==21069== Copyright (C) 2003-2010, and GNU GPL'd, by Nicholas Nethercote 
==21069== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info 
==21069== Command: /bin/sleep 5 
==21069== 
==21070== Command: /usr/bin/less 
==21070== 
==21068== 
(END) ==21069== 
==21070== 
==21067==

我的测试脚本的内容，testscript.sh：

ls | sleep 5 | less

从--massif-out-file=myProcesses".%p"生成的文件之一稀疏内容（myProcesses.21055）：

desc: --peak-inaccuracy=0.5 --pages-as-heap=yes --massif-out-file=myProcesses.%p 
cmd: ./testscript.sh 
time_unit: i 
#----------- 
snapshot=0 
#----------- 
time=0 
mem_heap_B=110592 
mem_heap_extra_B=0 
mem_stacks_B=0 
heap_tree=empty 
#----------- 
snapshot=1 
#----------- 
time=0 
mem_heap_B=118784 
mem_heap_extra_B=0 
mem_stacks_B=0 
heap_tree=empty 
... 
#----------- 
snapshot=18 
#----------- 
time=108269 
mem_heap_B=1708032 
mem_heap_extra_B=0 
mem_stacks_B=0 
heap_tree=peak 
n2: 1708032 (page allocation syscalls) mmap/mremap/brk, --alloc-fns, etc. 
n3: 1474560 0x4015E42: mmap (mmap.S:62) 
    n1: 1425408 0x4005CAC: _dl_map_object_from_fd (dl-load.c:1209) 
    n2: 1425408 0x4007109: _dl_map_object (dl-load.c:2250) 
    n1: 1413120 0x400CEEA: openaux (dl-deps.c:65) 
    n1: 1413120 0x400D834: _dl_catch_error (dl-error.c:178) 
     n1: 1413120 0x400C1E0: _dl_map_object_deps (dl-deps.c:247) 
     n1: 1413120 0x4002B59: dl_main (rtld.c:1780) 
     n1: 1413120 0x40140C5: _dl_sysdep_start (dl-sysdep.c:243) 
     n1: 1413120 0x4000C6B: _dl_start (rtld.c:333) 
      n0: 1413120 0x4000855: ??? (in /lib/ld-2.11.1.so) 
    n0: 12288 in 1 place, below massif's threshold (01.00%) 
    n0: 28672 in 3 places, all below massif's threshold (01.00%) 
    n1: 20480 0x4005E0C: _dl_map_object_from_fd (dl-load.c:1260) 
    n1: 20480 0x4007109: _dl_map_object (dl-load.c:2250) 
    n0: 20480 in 2 places, all below massif's threshold (01.00%) 
n0: 233472 0xFFFFFFFF: ??? 
#----------- 
snapshot=19 
#----------- 
time=108269 
mem_heap_B=1703936 
mem_heap_extra_B=0 
mem_stacks_B=0 
heap_tree=empty 
#----------- 
snapshot=20 
#----------- 
time=200236 
mem_heap_B=1839104 
mem_heap_extra_B=0 
mem_stacks_B=0 
heap_tree=empty

地块继续在我的其余文件中抱怨堆分配。请注意，这与您的错误非常相似。

我推理你的版本valgrind是在调试模式下构建的，导致触发器触发。从源代码重建（我使用this，默认值为./configure）将解决此问题。

无论哪种方式，这seems to be expected with Massif。

来源

2012-03-24 21:49:11 MrGomez

我在复制粘贴问题到这个SO问题上犯了一个错误。我的测试脚本确实使用了“追踪儿童”而不是“追踪儿童”。感谢您收到此错误。我编辑了这个问题来解决这个错误。 – 2012-03-24 23:56:42

没问题。就回答问题而言，请包括您正在使用的'valgrind'版本。这似乎是你的命令行或程序“foo”的处理问题，而不是缺乏处理管道进程的'valgrind'特性。 – MrGomez 2012-03-24 23:58:54

我正在使用valgrind v3.6.1。 – 2012-03-25 00:13:20

一些程序允许你预装libmemusage.so库，得到一个什么样被分配的内存分配记录的报告：

$ LD_PRELOAD=libmemusage.so less /etc/passwd 

Memory usage summary: heap total: 36212, heap peak: 35011, stack peak: 15008 
     total calls total memory failed calls 
malloc|   39   5985    0 
realloc|   3    64    0 (nomove:2, dec:0, free:0) 
calloc|  238   30163    0 
    free|   51   11546 
Histogram for block sizes: 
    0-15   128 45% ================================================== 
    16-31    13 4% ===== 
    32-47   105 37% ========================================= 
    48-63    2 <1% 
    64-79    4 1% = 
    80-95    5 1% = 
    96-111    3 1% = 
    112-127    3 1% = 
    160-175    1 <1% 
    192-207    1 <1% 
    208-223    2 <1% 
    256-271    1 <1% 
    432-447    1 <1% 
    560-575    1 <1% 
    656-671    1 <1% 
    768-783    1 <1% 
    944-959    1 <1% 
1024-1039   2 <1% 
1328-1343   1 <1% 
2128-2143   1 <1% 
3312-3327   1 <1% 
7952-7967   1 <1% 
8240-8255   1 <1%

尽管我必须承认，它并不总是奏效 - LD_PRELOAD=libmemusage.so ls永远不会报告任何东西，例如 - 我希望我知道允许它工作或不工作的条件。

来源

2012-03-22 01:25:31 sarnold

这很有趣，我希望我知道一种方法可以将这一点用于我的特定设置。不过谢谢！ – 2012-03-24 19:04:28

使用valgrind跟踪管道命令的内存使用情况

回答

相关问题