Solaris: pmap сообщает о другом размере виртуальной памяти, чем ps

Question

У меня есть процесс, выполняющийся на Solaris (SunOS m1001 5.10 sun4v sparc) и осуществляющий контроль за используемой общей виртуальной памятью.

Периодически бегущие пс показали, что VSZ рос линейно с течением времени с прыжками в 80 кбайт и что он продолжает расти, пока не достигнет предела 4 ГБ, в котором он находится вне адресного пространства, и все начинает разваливаться.

while true; do ps -ef -o pid,vsz,rss|grep 27435 ; sleep 5; done > ps.txt 

Я подозревал утечку памяти и решил продолжить исследование с pmap. Но pmap показывает, что VSZ не растет вообще, а остается стабильным. Также все карты файлов, карты общей памяти и кучи сохраняли одинаковый размер.

while true; do pmap -x 27435 |grep total; sleep 5; done > pmap.txt 

Мой первый вопрос: Почему пс и ртар производить различные ВСЗ для того же процесса?

Я могу представить, что размеры кучи вычисляются по-разному (например, использование кучи против указателя максимальной кучи), поэтому начали думать в направлении фрагментации кучи. Затем я использовал libumem и mdb для получения подробных отчетов об allocted памяти в разное время и заметил, что в выделенной памяти нет никакой разницы.

mdb 27435 < $umem_cmds 
::walk thread |::findstack !tee>>umemc-findstack.log 
::umalog !tee>>umem-umalog.log 
::umastat !tee>>umem-umastat.log 
::umausers !tee>umem-umausers.log 
::umem_cache !tee>>umem-umem_cache.log 
::umem_log !tee>>umem-umem_log.log 
::umem_status !tee>>umem-umem_status.log 
::umem_malloc_dist !tee>>umem-umem_malloc_dist.log 
::umem_malloc_info !tee>>umem-umem_malloc_info.log 
::umem_verify !tee>>umem-umem_verify.log 
::findleaks -dv !tee>>umem-findleaks.log 
::vmem !tee>>umem-vmem.log 
*umem_oversize_arena::walk vmem_alloc | ::vmem_seg -v !tee>umem- oversize.log 
*umem_default_arena::walk vmem_alloc | ::vmem_seg -v !tee>umem-default.log 

Так что мой второй вопрос: , что это лучший способ, чтобы выяснить, что является причиной растущей ВСЗ сообщенный пс.

Answer 1

Если вы запускаете подозрительный процесс с LD_PRELOAD=libumem.so, то в точке, где «все это разваливается» вы можете gcore - и затем запустить MDB над ним с umem dcmds, таких как ::findleaks -dv.

Если вы посмотрите на все сопоставления, перечисленные в выводе pmap (1), а не только на итоговые данные для процесса, вы получите гораздо лучшее представление о том, где искать. Первое, что я ищу, это сегменты кучи, анома и стека.