Отслеживание использования памяти по конвейерным командам с помощью valgrind - PullRequest
1 голос
/ 22 марта 2012

У меня есть пара процессов, на которых запущен инструмент, который я написал, и который соединен трубами, и я хотел бы измерить использование их собранной памяти с помощью 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 для отслеживания этого, я получаю (ради аргумента) 10% использования памяти на первом foo, а затем еще 10% на втором foo до завершения myProcesses.script.Это то, что я хочу измерить: использование обоих процессов.Вместо этого Valgrind возвращает следующую ошибку:

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

Есть ли способ сбора данных об использовании памяти для команд, которые я использую по трубопроводу (используя valgrind)?Или подобный инструмент, который я могу использовать, чтобы точно автоматизировать эти измерения?

Числа, которые top возвращает во время опроса, кажутся мне волнистыми, и я ищу точные и повторяемые измерения.Если у вас есть предложения по альтернативным инструментам, я также приветствую их.

EDIT - Исправлена ​​опечатка с опцией valgrind.

EDIT 2 - По некоторым причинам, кажется, что опция --pages-as-heap доставляет нам проблемы с исполняемыми файлами, которые мы тестируем.Ваши примеры работают нормально.Новая страница создается каждый раз, когда мы вводим не встроенную функцию (переполнение стека - хе).Мы хотели посчитать их, но они относительно незначительны в масштабах использования памяти, которое мы тестируем.(Возможно, нет вызовов функций в ls или less?) Удаление --pages-as-heap помогло снова начать тестирование.Спасибо MrGomez за большую помощь.

Ответы [ 2 ]

3 голосов
/ 25 марта 2012

С правильной версией 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) решит проблему.

В любом случае, это кажется ожидаемым с массивом .

0 голосов
/ 22 марта 2012

Некоторые программы позволяют предварительно загружать библиотеку 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 никогда ничего не сообщает, например - и я хотел бы знать условия, которые позволяют ему работать или не работать.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...