1,179.83 MB (100.0%) -- explicit
├────534.73 MB (45.32%) ── heap-unclassified
├────455.78 MB (38.63%) -- window-objects
│ ├──421.44 MB (35.72%) -- top(none)/detached/window([system])
│ │ ├──420.85 MB (35.67%) -- js/compartment([System Principal], about:blank)
│ │ │ ├──261.13 MB (22.13%) -- gc-heap
meaning we probably need a few more probes to be able to analyse , right ?
├─────52.61 MB (02.95%) -- js-non-window
│ ├──34.21 MB (01.92%) -- compartments
│ │ ├──31.35 MB (01.76%) ++ non-window-global
│ │ └───2.86 MB (00.16%) ++ no-global
│ └──18.40 MB (01.03%) ++ (2 tiny)
├─────27.84 MB (01.56%) ++ window-objects
└─────14.60 MB (00.82%) ++ (16 tiny)
Then do something already! :-P
Ok, then that is a major problem.
Ben's is different - more memory tracked in the window-objects than I
usually see. That could be memory leaks or a misbehaving extension.
- irving -
while you're at it, you may as well enable msgdb:5 logging to surface
whether dbs are closing
If you can reliably reproduce, the way to analyse heap-unclassified is
to run DMD (https://wiki.mozilla.org/Performance/MemShrink/DMD)
--
Florian Quèze
So can you try running with patch from https://bugzilla.mozilla.org/show_bug.cgi?id=765074 ?
I checked today and I'm seeing pretty much the same behaviour as Ludo (>
2GB, mostly heap-unclassified). I just made a --disable-jemalloc build
locally and ran it in valgrind, and whilst it's pretty difficult to
separate real leaks from stuff that just isn't cleaned up properly at
shutdown, https://bugzilla.mozilla.org/show_bug.cgi?id=844148 did jump
out to me fairly quickly (although I'm not sure how much it's worth in
the real world yet).
Regards
Chris
I have a test folder of 1 million messages comprising 4GB of mbox data and I do not get such high numbers, when just viewing them.
______________________________________________________________
> Od: "Ludovic Hirlimann" <lud...@mozilla.com>
> Komu: <tb-pl...@mozilla.org>
> Dátum: 02.04.2013 14:02
> Predmet: Re: 2.2 Gib :(
>
>----------
It probably get cycled a lot - eg older messages are removed because they aren't relevant old cron log don't serve you years after.
Ludo
Also, not saying it is the case here, but it is possible the numbers may
be off. ref https://bugzilla.mozilla.org/show_bug.cgi?id=857036
in addition, the figure might be off somewhat.
ref https://bugzilla.mozilla.org/show_bug.cgi?id=857036
On 4/2/2013 9:10 AM, acel...@atlas.sk wrote: