memory - valgrindを使用したパイプコマンドのメモリ使用量の追跡

Question

私が書いたツールを実行しているいくつかのプロセスがパイプで結合されており、それらの収集されたメモリ使用量をで測定したいと思いますvalgrind。これまでのところ、私は次のようなことを試しました：

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

ここmyProcesses.scriptで、私のツールに相当するものをfoo2回実行します。例：

foo | foo > /dev/null

Valgrindは、私が期待する方法で、これの収集されたメモリ使用量をキャプチャしていないようです。これを追跡するために使用する場合top、（議論のために）最初に10％のメモリ使用量を取得し、次に、完了する前にfoo別の10％が2番目に収集します。これは私が測定したい種類のものです：両方のプロセスの使用量。代わりに、Valgrindは次のエラーを返します。foomyProcesses.script

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に感謝します。

score 3 · Accepted Answer

正誤表に記載されている正しいvalgrindバージョンでは、これはValgrind3.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"（）によって生成されたファイルの1つからのスパースコンテンツ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デバッグモードでビルドされており、アサートが発生していると考えられます。ソースからの再構築（デフォルトでぶら下がっている状態でこれ./configureを使用しました）で問題が修正されます。

いずれにせよ、これはMassifで予想されるようです。

score 0 · Accepted Answer

一部のプログラムでは、ライブラリをプリロードして、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（たとえば、何も報告しない）、それが機能するか機能しないかを許可する条件を知っていればいいのですが。

memory - valgrindを使用したパイプコマンドのメモリ使用量の追跡

2 に答える 2

Related

Reference