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

Question

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

Периодически запускаемый ps показывал, что 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

Мой первый вопрос: почему ps и pmap создают разные VSZ для одного и того же процесса?

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

 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

Итак, мой второй вопрос: каков наилучший способ выяснить, что вызывает рост VSZ, о котором сообщает ps.

Answer 1

Я заметил, что этот вопрос все еще открыт, и хотел добавить, чем закончилась эта история.

После долгих поисков я связался со службой поддержки Solari и отправил им способ воспроизвести проблему. Они подтвердили, что в ядре была ошибка, вызвавшая такое поведение.

К сожалению, я не могу подтвердить, что они выпустили патч, так как я ушел из компании, в которой я тогда работал.

Спасибо, Джеф

Answer 2

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

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