dtrace discuss - Feb 2009 - Memory usage for C++ Application is growing

Hi ,

                  I have c++ server application in solaries 10 . Day by day
memory usage is growing

i try to find memory leaks with MDB and DTRACE and no leaks found. how can we
find reason for growing memory  , can we know which memory sigment is cause for
growing memory usage

Thanks in Advance.
   Rao
-- 
This message posted from opensolaris.org

hmm
-- 
This message posted from opensolaris.org

Try looking at allocations and ustack() where allocations happen.
When you say that you tried to find leaks with DTrace, what did you
try exactly?

Adam

On Feb 27, 2009, at 11:01 AM, venkat wrote:
> Hi ,
>
>                  I have c++ server application in solaries 10 . Day  
> by day memory usage is growing
>
> i try to find memory leaks with MDB and DTRACE and no leaks found.  
> how can we find reason for growing memory  , can we know which  
> memory sigment is cause for growing memory usage
>
> Thanks in Advance.
>   Rao
> -- 
> This message posted from opensolaris.org
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org

--
Adam Leventhal, Fishworks                        http://blogs.sun.com/ahl

I bet your application allocates and frees memory frequently, and further more
the byte size of each allocation and deallocation is quite small compared to the
default 8K memory page size on SPARC and 4KB memory page size on x86. You may
use the following dtrace script to understand the memory allocation and free
behavior of your application.

# cat ./malloc.d
#!/usr/sbin/dtrace -s
pid$1::malloc:entry
{
  @alloc["malloc count"] = count();
  @alloc_avg_size["malloc avg size"] = avg(arg0);
}

pid$1::free:entry
{
  @free["free count"] = count();
}

profile:::tick-10sec
{
  printa(@alloc);
  printa(@alloc_avg_size);
  printa(@free);
  clear(@alloc);
  clear(@alloc_avg_size);
  clear(@free);
}

# dtrace -s ./malloc.d <pid>
-- 
This message posted from opensolaris.org

Did you try libumem.so?

http://blogs.sun.com/ahl/entry/solaris_10_top_11_20

P.S. more than often I''ll find C++ memory leak caused by deallocators
not declared as virtual when they should be... :-)

-----Original Message-----
From: dtrace-discuss-bounces at opensolaris.org [mailto:dtrace-discuss-bounces
at opensolaris.org] On Behalf Of venkat
Sent: Saturday, February 28, 2009 3:02
To: dtrace-discuss at opensolaris.org
Subject: [dtrace-discuss] Memory usage for C++ Application is growing

Hi ,

                  I have c++ server application in solaries 10 . Day by day
memory usage is growing

i try to find memory leaks with MDB and DTRACE and no leaks found. how can we
find reason for growing memory  , can we know which memory sigment is cause for
growing memory usage

Thanks in Advance.
   Rao
-- 
This message posted from opensolaris.org
_______________________________________________
dtrace-discuss mailing list
dtrace-discuss at opensolaris.org

Venki,

You can try the scripts listed here :
http://blogs.sun.com/sanjeevb

This uses the approach which Adam suggested.

Thanks and regards,
Sanjeev
On Mon, Mar 09, 2009 at 01:11:35PM -0700, Adam Leventhal
wrote:
> Try looking at allocations and ustack() where allocations happen.
> When you say that you tried to find leaks with DTrace, what did you
> try exactly?
>
> Adam
>
> On Feb 27, 2009, at 11:01 AM, venkat wrote:
>
>> Hi ,
>>
>>                  I have c++ server application in solaries 10 . Day by 
>> day memory usage is growing
>>
>> i try to find memory leaks with MDB and DTRACE and no leaks found. how 
>> can we find reason for growing memory  , can we know which memory 
>> sigment is cause for growing memory usage
>>
>> Thanks in Advance.
>>   Rao
>> -- 
>> This message posted from opensolaris.org
>> _______________________________________________
>> dtrace-discuss mailing list
>> dtrace-discuss at opensolaris.org
>
>
> --
> Adam Leventhal, Fishworks                        http://blogs.sun.com/ahl
>
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org
-- 
----------------
Sanjeev Bagewadi
Solaris RPE 
Bangalore, India

Hi all,
    thanks for ur response ,

as mention sanjeev mention  findleaks.pl   is showing good report and 

one more thing i want ask here is about lazy deallocation in solaries ,

memory allocated for local variables  the memory usage is increasing , but after
scope of variable gone , still memory usage for binary is same.

why its not coming back to intial memeory usage point . 

can any body explan ?


Thanks,
 Venkat


Thanks ,
  Venkat
-- 
This message posted from opensolaris.org

Venkat,

When malloc is called, if there is not enough ADDRESS space for the
allocation, sbrk/brk is called to increase the address space.
So the Virtual size increases.

Solaris is a demand paged system. When the for mentioned address
space is touched, a page fault occurs and RAM is assocuated with the
page. The RSS increases.

When free is called the
address space is available in the malloc "arena". The RAM is still
associated with the page.

If the system gets low on memory, then the page scanner runs and if the
aforementioned page is not being used in a timely manner, 
then it is paged out and the RAM becomes available. The RSS shrinks.

If you want a different algorithm try libmapmalloc.

man mapmalloc.

But be warned, the minor page faults may increase significantly.

rick


On Fri, Mar 13, 2009 at 12:25:04PM -0700, venkat wrote:
> Subject: Re: [dtrace-discuss] Memory usage for C++ Application is growing
> Hi all,
>     thanks for ur response ,
> 
> as mention sanjeev mention  findleaks.pl   is showing good report and 
> 
> one more thing i want ask here is about lazy deallocation in solaries ,
> 
> memory allocated for local variables  the memory usage is increasing , but
after  scope of variable gone , still memory usage for binary is same.
> 
> why its not coming back to intial memeory usage point . 
> 
> can any body explan ?
> 
> 
> Thanks,
>  Venkat
> 
> 
> Thanks ,
>   Venkat
> -- 
> This message posted from opensolaris.org
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org
-- 

Rickey C. Weisner 
Software Development and Performance Specialist 
Principal Field Technologist
Systems Quality Office
cell phone: 615-308-1147
email: rick.weisner at sun.com