So, you're probably being burned by the fact that the process is being
frequently stopped by DTrace to determine the ustack values. If you only
need the last n, consider using a ring buffer (which won't stop the process
until the DTrace enabling is terminated). Also, if it's a memory leak that
you're trying to track down, strongly consider using libumem and
::findleaks instead -- it should take you right to the leak! (See
umem_debug(3MALLOC) for details.)
- Bryan
On Tue, Apr 17, 2018 at 11:27 PM, Robert <robert.ayrapet...@gmail.com>
wrote:
> Hi there!
>
> Hope this wonderful community is still alive.
>
> So, I have a "leaking" process:
>
> sudo timeout 10 dtrace -n 'pid$target::malloc:entry { @ = count(); }' -p
> 24063
> dtrace: description 'pid$target::malloc:entry ' matched 1 probe
> 1474858
>
> Around 150K malloc-s per sec. And it leaks somewhere (under a certain load
> only).
>
> What I'm trying to do is to store all malloc\free calls params\results
> along with stack traces.
>
> Then I would analyze collected logs and find a leaking spot (I really hope
> so).
>
> Everything works fine, except ustack() calls - they are incredibly slow
> and kill the performance almost right away.
>
> Process's CPU usage drops down to zero and I can see how log file is
> growing with about one record per second (instead of 150K\sec).
>
> Is there some workaround to make ustack() calls to work in real-time? Or
> maybe I've screwed up something...
>
> Please help! Thanks!
>
-------------------------------------------
dtrace-discuss
Archives: https://www.listbox.com/member/archive/184261/=now
Modify Your Subscription:
https://www.listbox.com/member/?member_id=25769126&id_secret=25769126-8d47a7b2
Powered by Listbox: http://www.listbox.com
