【问题标题】:Tracking memory usage of piped commands with valgrind使用 valgrind 跟踪管道命令的内存使用情况
【发布时间】:2012-03-27 08:19:58
【问题描述】:

我有几个运行我编写的工具的进程,它们通过管道连接,我想用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% 的内存使用率,然后在myProcesses.script 完成之前在第二个foo 上再收集10% 的内存使用率。这就是我想要衡量的事情:两个进程的使用情况。 Valgrind 反而返回以下错误:

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

有没有办法为我以管道方式使用的命令(使用valgrind)收集内存使用数据?或者我可以使用类似的工具来准确地自动化这些测量?

top 在投票时返回的数字对我来说似乎是手摇的,我正在寻求准确且可重复的测量结果。如果您对替代工具有建议,我也会欢迎。

编辑 - 修正了 valgrind 选项的拼写错误。

EDIT 2 - 出于某种原因,--pages-as-heap 选项似乎给我们正在测试的二进制文件带来了麻烦。你的例子运行良好。每次我们输入非内联函数时都会创建一个新页面(堆栈溢出 - 呵呵)。我们想计算这些,但它们在我们正在测试的内存使用规模中相对较小。 (也许lsless 中没有函数调用?)删除--pages-as-heap 有助于使测试再次工作。感谢 MrGomez 的大力帮助。

【问题讨论】:

  • 至于您的页面对齐问题,这显然与在massif中设置新的内存断点时失败的分页行为有关。我无法最终重现此问题,但我推测 --pages-as-heap=yes 在您在系统上调用的上下文中对此负责。显然,如果您希望探索错误情况,了解为什么在调试器中会遇到这种情况是最好的做法。 (请参阅下面的答案。)

标签: memory valgrind fork massif top-command


【解决方案1】:

在勘误表中给出了正确的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

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

我推测您的valgrind 版本是在调试模式下构建的,导致断言触发。从源代码重建(我使用 this 并使用默认值挂起 ./configure)将解决此问题。

不管怎样,这个seems to be expected with Massif

【讨论】:

  • 我在将问题复制粘贴到此 SO 问题时打错了字。我的测试脚本确实使用trace-children 而不是track-children。感谢您发现此错误。我已经编辑了问题以修复错字。
  • 没问题。至于回答问题,请同时包含您正在使用的valgrind 的版本。这似乎是您的命令行或程序 foo 的配置问题,而不是缺少 valgrind 处理管道进程的功能。
  • @AlexReynolds 你的命令对我有用。我已经更新了我的答案。
  • 有趣。将对此进行更多研究,并希望很快有结果。感谢您的调查。
  • @AlexReynolds 很高兴为您提供帮助。有时,我们所需要的只是具有不同系统配置的人员来帮助突出问题。
【解决方案2】:

一些程序允许您预加载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 从不报告任何东西——我希望我知道允许它工作或不工作的条件。

【讨论】:

  • 这很有趣,我希望我知道一种方法可以将它用于我的特定设置。不过谢谢!
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2011-05-16
  • 2013-01-14
  • 1970-01-01
  • 2011-01-18
  • 2017-06-17
  • 2017-02-14
  • 1970-01-01
相关资源
最近更新 更多