1

Solaris (SunOS m1001 5.10 sun4v sparc) で実行されているプロセスがあり、使用される仮想メモリの合計を監視していました。

定期的に ps を実行すると、VSZ が 80k バイトのジャンプで時間の経過とともに直線的に増加し、4GB の制限に達するまで増加し続け、その時点でアドレス空間が不足し、物事が崩壊し始めることが示されました。

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

私の 2 番目の質問は、ps によって報告された VSZ の増加の原因を突き止める最善の方法は何かということです。

4

2 に答える 2

0

疑わしいプロセスを で実行するとLD_PRELOAD=libumem.so、「すべてがバラバラ」になった時点で gcore を実行し、::findleaks -dv.

プロセスの合計だけでなく、pmap(1) の出力にリストされているすべてのマッピングを見ると、どこを見ればよいかがわかります。最初に探すのは、ヒープ、アノン、およびスタック セグメントです。

于 2016-02-29T03:58:58.610 に答える