Closed Bug 35663 Opened 25 years ago Closed 24 years ago

Severe memory bloat using Linux mail

Categories

(MailNews Core :: Backend, defect, P3)

Product:
MailNews Core
Component:
Backend
Platform:
x86
Linux
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: trudelle, Assigned: scottputterman)

Details

(Keywords: memory-footprint)

I just noticed that merely launching mail, opening my IMAP inbox, and reading one small text message results in 173 MB of memory allocation on Linux. It grows very rapidly from there. Opening a few more messages adds another 30 MB, opening a newsgroup, a bug and this message composition window adds another 55 MB. Sitting idle for an hour brought the total memory usage to 313 MB. This seems sub-optimal.
putting on dogfood radar
Keywords: dogfood
Adding to PDT+ radar. This much memory utilization will stop a lot of folks from being able to use the product as dogfood. If it is hard to reproduce, then we might remove the PDT+, but we need more input before we'd ignore such a bloat/leak.
Whiteboard: [PDT+]
I have been able to consistently reproduce this (currently at 469MB), and my machine is available if needed.
Seth, are you the right person to take a first look at this Linux problem?
Assignee: selmer → sspitzer
adding alecf and bruce to the cc list.
I doubt that this is Linux only. Can anyone verify?
I also see bloat on the other platforms I use, Mac OS 8.6 and Win98, but Linux is far worse. For instance, on Mac, I can launch and view a mail message using a 'mere' 26 MB.
Update on Win NT: When I launched just mail, opened my inbox and read a Mail it comsumes 40 MB memory. When I open browser to update this bug it comsumes 10 MB more (or totally 50 MB) .
Putting on [dogfood+] radar.
Whiteboard: [PDT+] → [dogfood+]
It has been about 8 days as dogfood without any update... is there any progress? Any ideas? Thanks, Jim
no, I still haven't investigated. adding other x-heads to the list, to see if they see this bad bloat.
passing the buck to alecf. I'm not going to get to this any time soon.
Assignee: sspitzer → alecf
I will try to look at this on wednesday. I'm wondering if biff is leaking or something
Status: NEW → ASSIGNED
Whiteboard: [dogfood+] → [dogfood+] 5/4
Target Milestone: --- → M16
Mass moving M16 to M17 - look for nsbeta2 before anything else.
Target Milestone: M16 → M17
I don't understand your comment Steve, I thought PDT considered dogfood+ to be even higher priority than nsbeta2+.
You're right. Luckily, our dogfood+ bug list is very short. So what I should have said was: Look for dogfood+ and nsbeta2+ bugs before anything else.
I really don't know what I'm supposed to do about this. I'm trying some of the XPCOM bloat stuff now but I still haven't seen anything get this big on linux in a while.
ok, I just spent some time with bloaty, and the best I can figure is that we're leaking nsMsgHdr objects... but they aren't THAT big and after poring over messages my process is not getting any bigger than about 55 megs on a 2000 message folder. Since this is hard to reproduce, I'm removing the dogfood+ for re-evaluation.
Whiteboard: [dogfood+] 5/4
dogfood-. Lisa, can we get QA help reproducing?
Whiteboard: [dogfood-]
I'll send this around the group to see if reproducible. I will also ask in the irc #qa channel.
Have bug 34871 fixed yet? I know I was still removing the following file for workaround on Linux... I did notice if I don't use the following workaround, it will perform abnormal.....I am still investigating ...... package/defaults/pref/config-ns.js
bug http://bugzilla.mozilla.org/show_bug.cgi?id=40020 needs to be fixed for memory issues as well.
I saw bug 40020 problem...but haven't see such serious memory problem yet....
bug 34871 shouldn't have anything to do with this... bug 40020 is due to something pav checked and should not have, he's backed it out.
So, what's this bug problem???...I still cannot reproduce this problem....
Problem is the same as originally described, I can still reproduce using the latest build, which currently has 581 MB RAM allocated. Machine remains available for anyone to reproduce.
Here's the bloatblame for a 662 message folder: http://www.maubi.net/mozilla/bloat/2000-06-02-mail-fun.html.gz http://www.maubi.net/mozilla/bloat/2000-06-02-mail-mod.html.gz Sadly, I only get about 33Mb of bloat, so maybe somebody oughtta try running --trace-malloc on trudelle's machine.
Both of those URLs were 403 forbidden.
fucking umask. try again.
Following is what I got from today's 06-05-08-M16 Linux commercial build: 1) For reading a mail message read Mem: 128092K av, 118056K used, 10036K free 2) For reading more messages: Mem: 128092K av, 119432K used, 8660K free 3) For reading newsgroup messages: Mem: 128092K av, 120220K used, 7872K free 4) For idle 1 hour after above scenarios: Mem: 128092K av, 120368K used, 7724K free
Peter - do you have this problem if you switch to the alternate 3-pane configuration in prefs (where you only show the mail folders, thread pane, message pane) and the sidebar is hidden?
somehow I have a feeling this is something very specific to peter's personal data (prefs, specific mail messages, etc) so we need to actually look at his machine :(
I could try a fresh profile, but I'm at home today and have never been able to use eXceed to get an X session on any machine.
Okay, got it. Using a fresh profile, with my personal IMAP account, with 263 messages in the Inbox, loading the inbox, plus one 5K message uses a total of 268,000K, regardless of sidebar state, according to gtop's Resident Sizes of Processes pane. Adding the default start page adds 170,000K. Could gtop be screwed up? Other possibly salient facts are that this is a dual-processor box with 512MB RAM, shared by my team.
wait, this is on exceed? that might have something to do with it..
This last run was my first on eXceed, all the others were run purely local.
moving to M18 and marking nsbeta3
Keywords: nsbeta3
Target Milestone: M17 → M18
peter, can you try this out with a 7/27 build or later? I just checked some stuff in that should reduce bloat in the thread pane.
Using today's M18 opt verification bits: ./netscape -mail -> Select User Profile appears 94,640K Start Mozilla -> 3pane appears 180,040K Select Inbox -> IMAP password dialog appears 221,312K Enter password, click okay -> Inbox loads 249,408K Select a small, text message 257,376K Select an HTML message (Wired News) 283,136K Open nav window (my.netscape.com) 336,000K (and continues to grow at a rate of 5-6 MB per minute.)
Keywords: footprint
Adding mail4 triage nomination keyword.
Keywords: mail4
Mail triage marking [nsbeta3-].
Whiteboard: [dogfood-] → [dogfood-][nsbeta3-]
Sorry for the extra mail. Removing mail4 keyword.
Keywords: mail4
reassign to putterman for further investigation
Assignee: alecf → putterman
Status: ASSIGNED → NEW
> Could gtop be screwed up? I could be wrong but I think gtop gives vastly inflated numbers for processes that use lots of threads. To total on the "Resident Sizes of Processes" page is the sum of the sizes for each thread. That means that if you have 10 threads sharing the same memory, the reported size is 10 times bigger than what is really being used. I gtop it routinely reports memory usage larger than my memory and swap space combined, even when my system shows no signs of memory distress.
QA Contact: lchiang → esther
Keywords: dogfood → nsdogfood
Target Milestone: M18 → ---
Keywords: nsdogfood-
Keywords: nsdogfood
Can this be closed now that the outliner branch has landed?
Keywords: nsbeta3
Whiteboard: [dogfood-][nsbeta3-]
The problem described no longer occurs in current builds. GTop and Top both seem to report the same memory usage multiple times, but even accounting for that, there was a severe problem here.
removing the RDF data soure & content model reduced our memory useage significantly. marking fixed.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
verified. (outliner did the trick, silly RDF :-)
Status: RESOLVED → VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.