|
From: Paulo M. G. <mo...@kd...> - 2008-05-28 10:56:36
|
Hi, I have the need to know which objects are consuming the majority of the memory, e.g.: type: MyFatClass instances: 1000 total size: 12MB type: MyNotSoFatClass instances: 1500 total size: 7MB [...] I tried Massif but got scared with all that output. Is there an easy way to have this kind of information? Thanks, Paulo |
|
From: Nicholas N. <nj...@cs...> - 2008-05-28 22:36:56
|
On Wed, 28 May 2008, Paulo Moura Guedes wrote: > I have the need to know which objects are consuming the majority of the > memory, e.g.: > > type: MyFatClass > instances: 1000 > total size: 12MB > > type: MyNotSoFatClass > instances: 1500 > total size: 7MB > > [...] > > I tried Massif but got scared with all that output. Is there an easy way to > have this kind of information? Not directly. You might be able to get that kind of info indirectly from Massif, though. It tracks memory allocated at particular program points. If you know that all instances of MyFatClass are allocated at a small number of program points, you'll be able to see in Massif's output how much memory is consumed by MyFatClass. But you'll have to understand Massif's output to do this; I recommend reading the manual... Nick |
|
From: Paulo M. G. <mo...@kd...> - 2008-05-29 13:26:35
|
On Wednesday 28 May 2008 23:36:20 Nicholas Nethercote wrote: > On Wed, 28 May 2008, Paulo Moura Guedes wrote: > > I have the need to know which objects are consuming the majority of the > > memory, e.g.: > > > > type: MyFatClass > > instances: 1000 > > total size: 12MB > > > > type: MyNotSoFatClass > > instances: 1500 > > total size: 7MB > > > > [...] > > > > I tried Massif but got scared with all that output. Is there an easy way > > to have this kind of information? > > Not directly. You might be able to get that kind of info indirectly from > Massif, though. It tracks memory allocated at particular program points. > If you know that all instances of MyFatClass are allocated at a small > number of program points, you'll be able to see in Massif's output how much > memory is consumed by MyFatClass. But you'll have to understand Massif's > output to do this; I recommend reading the manual... Thanks, I read it in the meanwhile :) I can see in massif output where the majority of the memory is allocated. Though, I'm pretty sure those objects get destroyed after a while as they go out of scope (they were allocated on the stack, new operator was not used), but my application memory keeps groing. I would need to find out (filter) the allocations which are not deallocated as time goes by. Any ideas on how to find this information? Thanks, Paulo |
|
From: Paul W. <pa...@bl...> - 2008-05-29 14:39:41
|
On Thu, May 29, 2008 at 02:26:39PM +0100, Paulo Moura Guedes wrote: > but my application memory keeps groing. I would need to find out (filter) > the allocations which are not deallocated as time goes by. Any ideas on > how to find this information? Raymond Chen had a good tip for this. Make it leak, then look at the memory. If you're leaking something, then if you look at a few memory addresses, odds are you'll find the thing that's leaking. His explaination is better: http://blogs.msdn.com/oldnewthing/archive/2005/08/15/451752.aspx Hope that helps, -- Paul Fsck, either way I'm screwed. -- petro Now *that* is the Sysadmin's motto. -- Peter da Silva |
|
From: Paulo M. G. <mo...@kd...> - 2008-05-29 15:17:59
|
On Thursday 29 May 2008 15:39:34 Paul Walker wrote: > On Thu, May 29, 2008 at 02:26:39PM +0100, Paulo Moura Guedes wrote: > > but my application memory keeps groing. I would need to find out (filter) > > the allocations which are not deallocated as time goes by. Any ideas on > > how to find this information? > > Raymond Chen had a good tip for this. Make it leak, then look at the > memory. If you're leaking something, then if you look at a few memory > addresses, odds are you'll find the thing that's leaking. > > His explaination is better: > > http://blogs.msdn.com/oldnewthing/archive/2005/08/15/451752.aspx I don't think I'm leaking memory. I think I have the references but the memory grows more than what I would expect. It's normal that it grows, because we're talking about a link checker, but I don't understand what could cause it to increase so rapidly. Thanks, Paulo |
|
From: Martijn V. <ma...@be...> - 2008-05-30 21:00:15
|
> I don't think I'm leaking memory. I think I have the references but the memory > grows more than what I would expect. It's normal that it grows, because we're > talking about a link checker, but I don't understand what could cause it to > increase so rapidly. I created a small utility to help to make sense of the massif output by plotting the data as a pie chart. I created it because I had exactly the same problem as you had so it might be helpful. I didn't get much reaction on the last version except that it didn't compile ;-), so I fixed it to compile with the default wxwidgets 2.6 or 2.8 on ubuntu. get it here: http://www.aaltjegron.nl/msplot/ -- martijn versteegh |
|
From: Paulo M. G. <mo...@kd...> - 2008-05-31 14:09:34
|
On Friday 30 May 2008 21:59:55 Martijn Versteegh wrote: > > I don't think I'm leaking memory. I think I have the references but the > > memory grows more than what I would expect. It's normal that it grows, > > because we're talking about a link checker, but I don't understand what > > could cause it to increase so rapidly. > > I created a small utility to help to make sense of the massif output by > plotting the data as a pie chart. I created it because I had exactly the > same problem as you had so it might be helpful. > > I didn't get much reaction on the last version except that it didn't > compile ;-), so I fixed it to compile with the default wxwidgets 2.6 or > 2.8 on ubuntu. > > get it here: > http://www.aaltjegron.nl/msplot/ It doesn't compile for me :( I have the lastest Kubuntu, Hardy. wxmain.cpp:241: error: call of overloaded ‘Append(const char [15])’ is ambiguous [...] If you're interested in a more detailed report please let me know :) Thanks Paulo |
|
From: Martijn V. <ma...@be...> - 2008-06-10 22:51:24
|
I did another minor update of msplot. I do hope it will compile with the default 2.9 wxwidgets now ;-) msplot is a visualisation tool for massif output. get it here http://www.aaltjegron.nl/msplot/ |
|
From: Martijn V. <ma...@be...> - 2008-06-10 23:39:08
|
> default 2.9 wxwidgets now hm. I don't hope this is a bad omen ;-) It was supposed to be 2.8. So you need wxgtk2.8-dev on debian derived distro's -- martijn |
|
From: Nicholas N. <nj...@cs...> - 2008-05-29 22:15:39
|
On Thu, 29 May 2008, Paulo Moura Guedes wrote: > I can see in massif output where the majority of the memory is allocated. > Though, I'm pretty sure those objects get destroyed after a while as they go > out of scope (they were allocated on the stack, new operator was not used), > but my application memory keeps groing. I would need to find out (filter) the > allocations which are not deallocated as time goes by. Any ideas on how to > find this information? Massif takes periodic snapshots of memory. If the size of the snapshots is larger in the later snapshots, then that indicates a possible leak, and the info in the snapshots should give you a fair idea of where that is. Are you sure you've understood Massif's output? It might be worth experimenting with a smaller test program. Also, if you use --stacks=yes Massif will do stack profiling as well (and run slower as a result). Nick |
|
From: Paulo M. G. <mo...@kd...> - 2008-05-31 14:18:47
|
On Thursday 29 May 2008 23:13:30 you wrote: > Massif takes periodic snapshots of memory. If the size of the snapshots is > larger in the later snapshots, then that indicates a possible leak, and the > info in the snapshots should give you a fair idea of where that is. Are > you sure you've understood Massif's output? It might be worth > experimenting with a smaller test program. IIRC, in Java world there is a concept when profiling memory objects which is the number of generations an object survives. It represents how many times an object survived to garbage collecting. This is what I really want to know, and each garbage collecting could be translated to one snapshot, in massif. I'm seing very high allocations but which are not relevant for me because in the next snapshot they are already destroyed. What is of interested to me is the ones who survived to > 1 snapshot. Does this make sense for you? :) Thanks, Paulo |
|
From: Nicholas N. <nj...@cs...> - 2008-06-01 02:06:04
|
On Sat, 31 May 2008, Paulo Moura Guedes wrote:
> IIRC, in Java world there is a concept when profiling memory objects which is
> the number of generations an object survives. It represents how many times an
> object survived to garbage collecting.
> This is what I really want to know, and each garbage collecting could be
> translated to one snapshot, in massif. I'm seing very high allocations but
> which are not relevant for me because in the next snapshot they are already
> destroyed. What is of interested to me is the ones who survived to > 1
> snapshot.
You can change the frequency of snapshots and detailed snapshots:
--detailed-freq=<N> every Nth snapshot should be detailed [10]
--max-snapshots=<N> maximum number of snapshots recorded [100]
Increasing these may make Massif run slower, but it may get you closer to
what you want.
Nick
|