dtrace discuss - Oct 2008 - query re memory profiling

Hi
I have a Dtrace script ( attached ) which examines memory usage, using
fbt:genunix:anon_resvmem:entry & return
On my T2000 it totals the 65k pages being reserved by my application, 
printing out the total in bytes.

Seems to work well, tested with a small app that malloced < 65 K, 
malloced 200M and mmapeed a 16M file and it appeared to get things correct.

Could I just get a second pair of eyes to eyeball it.

Basically I am looking at an app that seems to wander off the 
reservation in terms of memory usage, so wanted to rule out any bugs in 
the script.

I have the app compiled in debug ( -g ) so non-stripped, is there a way 
to get the stack of the calling app at the point in time of the 
anon_resvmem:entry & return.

Any help appreciated
Enda
-------------- next part --------------
A non-text attachment was scrubbed...
Name: memory.d
Type: text/x-dsrc
Size: 1596 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20081023/b446c9c8/attachment.bin>

> Hi
> I have a Dtrace script ( attached ) which examines
> memory usage, using
> fbt:genunix:anon_resvmem:entry & return
> Seems to work well, tested with a small app that
> malloced < 65 K, 
> malloced 200M and mmapeed a 16M file and it appeared
> to get things correct.
But is it tested with calls to free()?
> Basically I am looking at an app that seems to wander
> off the 
> reservation in terms of memory usage, so wanted to
> rule out any bugs in the script.
AFAICT ::anon_unresvmem:entry/self->size > 0/ would never fire because
self->size is only non-zero during calls to anon_resvmem. That''s
probably why there seems to be a memory leak.
> is there a way to get the stack of the calling app at the point in
> time of the anon_resvmem:entry & return.
ustack();

Other thoughts:

Most of those self-> variables (uid, pid, etc) seem unnecessary (though
harmless) because the values are just as easy to figure out from the :::return
as from the :::entry

Out of curiosity, why the test for non-NULL pr_psargs? Should unresvmem test for
it as well?

It seems like you''d want sth like this:

fbt:genunix:anon_resvmem:entry /arg1 != 0/ 
{ self->size = arg0; self->args = (char*) curpsinfo->pr_psargs; }

fbt:genunix:anon_resvmem:return /self->args != 0 && arg1 != 0/
{ printf(...); total[pid] += self->size; self->args = 0; }

fbt:genunix:anon_unresvmem:entry
{ self->size = arg0; self->args = (char*) curpsinfo->pr_psargs; }

fbt:genunix:anon_unresvmem:return /self->args != 0/
{ printf(...); total[pid] -= self->size; self->args = 0; }

Regards,
Ryan
--
This message posted from opensolaris.org