LIBUMEM говорит, что нет утечек памяти, но PRSTAT на Solaris показывает утечки? - PullRequest
Новая
       31

LIBUMEM говорит, что нет утечек памяти, но PRSTAT на Solaris показывает утечки?

2 голосов
/ 27 ноября 2011

У меня есть приложение, которое я пытался получить «без утечек памяти», я прошел тщательное тестирование на Linux, используя TotalView MemoryScape, и утечек не обнаружено. Я перенес приложение в Solaris (SPARC), и я пытаюсь найти утечку ...

Я использовал "LIBUMEM" на Solaris, и мне кажется, что он не обнаруживает утечек ...

Вот моя команда запуска: 

LD_PRELOAD=libumem.so UMEM_DEBUG=audit ./link_outbound config.ini

Затем я немедленно проверил PRSTAT в Solaris, чтобы увидеть, как использовалась память при запуске: 

PID USERNAME  SIZE   RSS STATE  PRI NICE      TIME  CPU PROCESS/NLWP       
  9471 root       44M   25M sleep   59    0   0:00:00 1.1% link_outbou/3

Затем я начал отправлять тысячи сообщений в приложение ... и со временем PRSTAT вырос .. 

PID USERNAME  SIZE   RSS STATE  PRI NICE      TIME  CPU PROCESS/NLWP       
  9471 root       48M   29M sleep   59    0   0:00:36 3.5% link_outbou/3

И как раз перед тем, как я в конце концов остановил это: 

PID USERNAME  SIZE   RSS STATE  PRI NICE      TIME  CPU PROCESS/NLWP       
  9471 root       48M   48M sleep   59    0   0:01:05 5.3% link_outbou/3

Теперь интересная часть, когда я использую LIBUMEM в этом приложении, показывает 48 МБ памяти, как показано ниже: 

pgrep link
9471
# gcore 9471
gcore: core.9471 dumped
# mdb core.9471
Loading modules: [ libumem.so.1 libc.so.1 ld.so.1 ]
> ::findleaks
BYTES             LEAKED         VMEM_SEG CALLER
131072                 7 ffffffff79f00000 MMAP
57344                  1 ffffffff7d672000 MMAP
24576                  1 ffffffff7acf0000 MMAP
458752                 1 ffffffff7ac80000 MMAP
24576                  1 ffffffff7a320000 MMAP
131072                 1 ffffffff7a300000 MMAP
24576                  1 ffffffff79f20000 MMAP
------------------------------------------------------------------------
           Total       7 oversized leaks, 851968 bytes

CACHE             LEAKED           BUFCTL CALLER
----------------------------------------------------------------------
           Total       0 buffers, 0 bytes
>

«7 негабаритных утечек, 851968 байт» никогда не изменится, если я отправлю 10 сообщений через приложение или 10000 сообщений ... это всегда «7 негабаритных утечек, 851968 байт». Означает ли это, что приложение не подтекает по "libumem"?

Что так расстраивает, так это то, что в Linux память остается постоянной, никогда не меняется ... но в Solaris я вижу этот медленный, но устойчивый рост.

Есть идеи, что это значит? Я правильно использую libumem? Что может быть причиной того, что PRSTAT показывает рост памяти?

Любая помощь по этому вопросу будет принята с благодарностью .... спасибо миллион.

Ответы [ 2 ]

2 голосов
/ 27 ноября 2011

Если столбец SIZE не увеличивается, значит, у вас нет утечки.

RSS (размер резидентного набора) - это объем памяти, который вы активно используетеЭто нормально, что это значение меняется с течением времени.Если бы вы протекали, SIZE росло бы со временем (а RSS могло бы оставаться постоянным или даже уменьшаться).

1 голос
/ 30 декабря 2011
  1. проверить эту страницу .предпочтительный вариант - UMEM_DEBUG=default, UMEM_LOGGING=transaction LD_PRELOAD=libumem.so.1., то есть тот, который я использую для отладки проблемы утечки памяти в Solaris, и он прекрасно работает для меня.
  2. , основываясь на моем опыте с RedHat REL version 5 и солярисом SunOS 5.9/5.10, процессом linuxобъем памяти не увеличивается постепенно, вместо этого кажется, что он захватывает большую порцию памяти, когда ему требуется дополнительная память, и использует их в течение длительного времени.(чисто на основе наблюдений, не исследовал механизм распределения памяти).поэтому вы должны отправить намного больше данных (10K сообщений не велики).
  3. Вы можете попробовать dtrace инструмент для проверки проблем с памятью в Solaris.

Джек

...