2.53 memory leaks

User Help for Seamonkey and Mozilla Suite
Post Reply
User avatar
mightyglydd
Posts: 9813
Joined: November 4th, 2006, 7:07 pm
Location: Hollywood Ca.

Re: 2.53 memory leaks

Post by mightyglydd »

-Px- wrote:this is on MOSTLY unmodified profile
#KeepFightingMichael and Alex.
User avatar
therube
Posts: 21703
Joined: March 10th, 2004, 9:59 pm
Location: Maryland USA

Re: 2.53 memory leaks

Post by therube »

I've recently found that increasing the parameter in about.config
Defaults are there for a reason.
While changing a default may help...

In one instance, you have a Developer who tells us the item in question is new, is not finished, that the technology behind it is new & not very pervasive, & that it is OK to change the default...

Otherwise, the defaults the Mozilla has, defaulted to, that have been validated (oh, I'm sure by telemetry ;-)), changing those, & the consequences of doing so, that's a different matter, & certainly in the category of "try this, maybe it can help alleviate...".
Fire 750, bring back 250.
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.19) Gecko/20110420 SeaMonkey/2.0.14 Pinball CopyURL+ FetchTextURL FlashGot NoScript
User avatar
ndebord
Posts: 1122
Joined: December 7th, 2002, 9:53 am

Re: 2.53 memory leaks

Post by ndebord »

webmoebius wrote:I've recently found that increasing the parameter in about.config:

javascript.options.mem.gc_allocation_threshold_mb

from its default 30 MB size to 96 MB or even 128 MB on Windows has decreased SM memory usage drastically. As I have just made this adjustment very recently, I'm still in the process of testing what difference it will make to SM memory and resource leakages over the next while. I have both SM 2.53-64 and 2.49.5-32 running on different Windows versions and on the latter version it has made a huge difference though interestingly more CPU utilization at times can occur on the multi-core processor it is running on. I've made the same adjustments to Firefox-ESR 32 and 64 bit releases of current and older versions and will also observe whether it reduces RAM consumption as shown in Windows task manager.
FWIW, I tried making the change to SM 2.53.3 32 bit from 30 to 96... memory usage went up by around 200 megs... average was between 500 and 600 meg... went back to 30 and it is back down to the 300 right now with 6 tabs open.

Nick
-N- Si vis pacem, para bellum
FrameWork, SeaMonkey(64-bit),Windows 10 Pro (X64- 21H2), WinPatrol, Malwarebytes & Panda Dome
RDaneel
Posts: 603
Joined: January 19th, 2004, 2:43 pm
Location: Puget Sound, WA
Contact:

Re: 2.53 memory leaks

Post by RDaneel »

Yes, to confirm, I also tried this, and for *my* set of tabs and windows, this ultimately lead to ~500MB "extra" in my working set - which went away immediately after I reset to the default of "30".

But hey - we all want to try out "magic bullets" when there might be one. ;)

And, since I still am not entirely clear why this thread has joined the ranks of the undead (it just won't die), I will say once again: if you think the memory usage has grown more than you like, just shut SM down, letting it save your tabs, and restart... no muss, no fuss, and ALL of your tabs are still there - but you won't pay for them (much) until you actually visit them again.

Just sayin'.
User avatar
Peter Creasey
Posts: 1340
Joined: October 26th, 2007, 2:32 pm
Location: Texas

Re: 2.53 memory leaks

Post by Peter Creasey »

RDaneel wrote: if you think the memory usage has grown more than you like, just shut SM down
For my purposes, the about:memory strategy has provided a quick remedy, so there's no reason to resort to a SM reboot.
. . . . . . . . . . Pete
webmoebius
Posts: 272
Joined: January 21st, 2007, 12:52 pm

Re: 2.53 memory leaks

Post by webmoebius »

ndebord wrote:FWIW, I tried making the change to SM 2.53.3 32 bit from 30 to 96... memory usage went up by around 200 megs... average was between 500 and 600 meg... went back to 30 and it is back down to the 300 right now with 6 tabs open. Nick
I haven't extensively tested this yet under a 64-bit Windows OS environment yet but will soon. However, I can confirm that with that parameter adjustment, SM 2.49.5 running under a 32-bit environment under Win-XP Pro SP3 used as little as 150 to 170 KILOBYTES with the mail client ONLY open from program start up when checked with the Windows task manager. With several page heavy tabs open and some with You Tube video listings and some tabs You Tube videos loaded (playing or paused), the memory consumption as reported by Windows task manager is anywhere between say 500 MB to about under 1 GB, occasionally exceeding that up to 1.2 GB to 1.3 GB. When RAM consumption exceeds that approximate amount, SM browser tends to freeze a lot temporarily and can take several minutes to recover even if tabs are closed as the browser is releasing resources. But case in point, prior to that parameter's adjustment, I would have to wait SEVERAL MINUTES for the Google News main page to render which made that page unuseable to visit. However, with that parameter change, I could quite quickly have the page rendered fully. Night and day difference.

I haven't yet extensively monitored the SM 2.53.X 64-bit version RAM consumption under Win-10 Pro version 2020.05 but that system has 16 GB RAM as opposed to a maximum of about 3.25 GB that is recognized under Win-XP Pro 32-bit environment. But I've made the same adjustments to all Mozilla SM and FF-ESR versions on the Win-10 Pro system as well as on the 32-bit Windows versions. The parameter in question relates to Javascript engine garbage collection memory usage headroom, and it makes sense to me that when a bit more RAM headroom is allocated, that I get far less browser temporary freezes when browser resources are used up close to exhaustion and JS engine garbage collection process has insufficient memory to perform the necessary browser system resource releases. Overall performance is much improved as confirmed by Windows Task manager so far. It is true however, that browser garbage collection does not fully compare to restarting the SM suite from scratch. So I'm limiting the number of concurrently open tabs while be conscious about how heavy the page in a tab might be and what is happening within a tab, e.g. animating graphics, videos, multimedia, etc, that might suck up browser and CPU resources.

Despite what my USER AGENT string posted in this thread may say, I'm actually using SM 2.49.5 when posting to this thread. The user agent string on this installation of SM was overridden for some other purpose in visiting certain sites.
User avatar
therube
Posts: 21703
Joined: March 10th, 2004, 9:59 pm
Location: Maryland USA

Re: 2.53 memory leaks

Post by therube »

Site specific, general.useragent.override.somesite.com (rather then global, general.useragent.override).
Fire 750, bring back 250.
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.19) Gecko/20110420 SeaMonkey/2.0.14 Pinball CopyURL+ FetchTextURL FlashGot NoScript
webmoebius
Posts: 272
Joined: January 21st, 2007, 12:52 pm

Re: 2.53 memory leaks

Post by webmoebius »

therube wrote:Site specific, general.useragent.override.somesite.com (rather then global, general.useragent.override).
Good idea. Just made that adjustment.
webmoebius
Posts: 272
Joined: January 21st, 2007, 12:52 pm

Re: 2.53 memory leaks

Post by webmoebius »

Peter Creasey wrote:For my purposes, the about:memory strategy has provided a quick remedy, so there's no reason to resort to a SM reboot.
Actually never knew about this trick. Works great and much better garbage collection.
jwq
Posts: 77
Joined: May 13th, 2004, 3:53 am

Re: 2.53 memory leaks

Post by jwq »

frg wrote:... I would like to know:

What OS including architecture, version and distribution.
How much ram?
I'd like to make sure we understand the problem (as there has been significant noise contributed to this thread by parties unaffected by the problem): SeaMonkey 2.53 memory usage increases with use to a point where performance rapidly degrades (lags, beachballs). Version 2.49 was not affected in this manner.

For me, this problem affects four separate installs of 2.53 on macOS 10.14 and 10.15. The most severly affected install is on a MacBook Pro (2019) with 16 GB of memory running macOS 10.15.

I use SeaMonkey strictly as a browser, so I am not using POP3, IMAP, news, RSS or calDAV. I had Flash disabled and, by coincidence, uninstalled Flash prior to posting to this thread. Some sites/services I use use OAuth but they are not the sites I work with day-to-day.
frg wrote: If you are starting with 2GB just for browsing please try a new test profile first.
The problem is not the 2 GB memory used on startup, the problem is the performance degradation. My sessionstore.json contains 9 windows with tens of tabs (the total number of tabs will be in the hundreds) with "only restore tabs when I need them" set. I'm perfectly fine with 2 GB of memory on startup because the performance is unaffected. It is only when total memory usage exceeds about 5 GB that performance rapidly degrades. Closing tabs does not reduce memory used and flushing the memory from about:memory provides only temporary relief by reducing usage by a few hundred MB (consistent with other reports). SeaMonkey 2.49 performance did not degrade in this manner.

I have already run in safe mode and see the same performance degradation, so it would appear to be unrelated to the change in extensions from NoScript and AdBlock in 2.49 to NoScript Legacy and UBlock in 2.53. [I believe this fact has been lost in the noise contributed to the thread by parties unaffected by the problem.]

A new profile has lower starting memory usage, and it would take significant time (5+ days) of use to reach the 5 GB memory use point. I tried to copy my sessionstore.json from the old profile to the new profile but SeaMonkey won't restore the session from the copied file. It's around that point I ran out of time and gave up. [I was speculating that I might have to copy the sessionstore.bak file as well for restore to function on the new profile?]

Looking at memory reports I saved in April, one site that SeaMonkey does not release memory from once tabs have been closed appears to be <https://www.stuff.co.nz/>. You and the other devs might be able to reproduce the increasing memory use by opening a window (so you have more than one window open) and opening articles in new tabs and then closing the tabs.
jwq
Posts: 77
Joined: May 13th, 2004, 3:53 am

Re: 2.53 memory leaks

Post by jwq »

RDaneel, a restart is not a low-cost workaround for me because SeaMonkey will not properly resume GitLab sessions (Chrome will resume GitLab sessions).

Let me clarify one point for you: this thread won't die because several people have a significant performance problem related to memory in version 2.53 which was not present in version 2.49. Problems don't go away just because some people on the internet make disparaging comments.

Those of us experiencing a problem with SeaMonkey 2.53 performance came here seeking support in resolving that problem. Now, it seems, we have two problems.

Just sayin'.
RDaneel
Posts: 603
Joined: January 19th, 2004, 2:43 pm
Location: Puget Sound, WA
Contact:

Re: 2.53 memory leaks

Post by RDaneel »

Sigh... not trying to imply there isn't a "problem"... but that a) it might just be part of life now, b) it's impact (in general) will mostly be of a "hmm - that's weird / annoying", given that c) there are several known "recoveries", i.e., actions that allow one to go an about one's business with a minimum of hassle.

I have certainly been "annoyed' with [apparently excess] memory usage over the years, given that I have used this package since it was called "Mozilla" in the early 2000s.

But I noticed fairly early after 64-bit builds became available from 3rd parties that the working set for SM could grow larger before the UI and behavioral negative effects became such that SM was unusable and you *had* to shut it down - which seemed like a Good Thing(tm). ;)

Just for the record, there is nothing wrong with seeing people that are NOT devs involved with "fixing" the memory usage issue BUT seem to be genuinely troubled by their browsers becoming harder to use... and pointing out a very easy and quick course of action that provides relief, and actually quite a bit more than is available from some other measures on the same order of trouble to employ.

But hey, the modern world - on and off the net - is certainly leaning in the direction of people being excessively thin-skinned and finding it way easier to just take offense as opposed to considering the actual semantic content of others words. :(
jwq
Posts: 77
Joined: May 13th, 2004, 3:53 am

Re: 2.53 memory leaks

Post by jwq »

Rdaneel, I wrote: "a restart is not a low-cost workaround for me..." The equivalent statement would be "a restart is not an easy nor a quick course of action that provides relief".

Can we concentrate on the problem, SeaMonkey performance degradation, please?
webmoebius
Posts: 272
Joined: January 21st, 2007, 12:52 pm

Re: 2.53 memory leaks

Post by webmoebius »

ndebord wrote:FWIW, I tried making the change to SM 2.53.3 32 bit from 30 to 96... memory usage went up by around 200 megs... average was between 500 and 600 meg... went back to 30 and it is back down to the 300 right now with 6 tabs open. Nick
Just did some brief tests with the parameter javascript.options.mem.gc_allocation_threshold_mb testing it at values of 96 MB and 128 MB under Win-10 pro 64-bit version, 2020.05 release with SM 2.53.1 64-bit edition. With only the mail client open and no browser window, the off the bat RAM consumption was over 200 MB, around 230 MB, far higher than the 150 KB to 170 KB under Win-XP Pro SP3. However, with a couple tabs of You Tube pages open, the RAM consumption rose to about 400 MB to below 500 MB, sometimes exceeding 500 MB. If the mail client window was open that may increase RAM consumption by about close to an additional 100 MB or so. In short, the off the bat RAM consumption under Win-10 Pro 64-bit edition and using SM 2.53.1, is much higher than under Win-XP Pro SP3 (32-bit). However, it appears that additional tabs with heavy pages results in somewhat shallower increase in RAM consumption compared to when running SM 2.49.5 32-bit under Win-XP Pro SP3. Under Win-10 Pro 64-bit OS, it seems that it starts off with much higher RAM consumption but in short, rises much less steeply with additional tabs open loading heavy pages.

When I decreased the parameter's value from 128 MB to 96MB under Win-10 Pro 64-bit OS, there wasn't a huge difference in RAM consumption though I did notice an INCREASE in the programs RAM consumption loading the same pages, the difference between the parameter's 96 MB and 128 MB maximum allocation notwithstanding. Under Win-XP SP3 environment, I noticed that during JS engine garbage collection such as when a tab is closed, the CPU usage and RAM usage as reported by Windows task manager temporarily spiked for a number of seconds, presumably due to garbage collection code executing and temporarily consuming more browser resources. After a number of seconds, the CPU usage and RAM usage both drop as reported by Windows task manager. If Win-XP Pro SP3 task manager already reports a RAM consumption of much over 1.2 GB to 1.3GB, the garbage collection routine has difficulty running as it seems that's where the SM resource ceiling tops out under this operating environment, as the garbage collection routine requires temporary additional browser resources, which under these circumstances is difficult to allocate due to resource scarcity. As a result, the SM suite can temporarily freeze for a number of seconds up to a number of minutes while garbage collection slowly works its way through to free resources while having little RAM headroom to work with. What it has shown at least is that this parameter drastically decreases RAM usage at least under this legacy OS environment with 32-bit SM versions. Under Win-10 Pro 64-bit I've got 16 GB of RAM to spare so I'm not terribly concerned when I've frequently worked under the constrains of SM 32-bit version which is now much improved with this parameter tweak.

In short, comparing the two Windows OS environments and the two 32-bit and 64-bit SM releases, I would summarize that the legacy OS environment starts off with minimal RAM usage but its increase can be much steeper with multiple tabs of heavy pages loaded, whereas the Win-10 Pro 64-bit environment running SM 64-bit results in much higher start up RAM consumption but appears to have somewhat shallower RAM consumption increases with more tabs of heavy pages loaded.
Last edited by webmoebius on August 15th, 2020, 1:33 am, edited 1 time in total.
User avatar
Frank Lion
Posts: 21173
Joined: April 23rd, 2004, 6:59 pm
Location: ... The Exorcist....United Kingdom
Contact:

Re: 2.53 memory leaks

Post by Frank Lion »

jwq wrote:RDaneelLet me clarify one point for you: this thread won't die because several people have a significant performance problem related to memory in...
Won't die? This thread, or the people, or the points made, really so different to this long dead thread? -

http://forums.mozillazine.org/viewtopic ... 4#p1267294

...or these? -

https://cse.google.com/cse?cx=003258325 ... =82j6724j2

jwq wrote: Problems don't go away just because some people on the internet make disparaging comments.
These disparaging comments wouldn't happen to include the suggestion that you file a bug on this, by any chance? You appear not to have done so.


Below are points you might want to think about in your attempt of 'Steps to Reproduce' -
jwq wrote: The problem is not the 2 GB memory used on startup, the problem is the performance degradation. My sessionstore.json contains 9 windows with tens of tabs (the total number of tabs will be in the hundreds) with "only restore tabs when I need them" set. I'm perfectly fine with 2 GB of memory on startup because the performance is unaffected.
What you're fine with is irrelevant. A 2 GB startup memory with a "only restore tabs when I need them" setting in place is not normal or reproducible, no matter how many tabs.
jwq wrote: A new profile has lower starting memory usage, and it would take significant time (5+ days) of use to reach the 5 GB memory use point.
You see nothing wrong or of significance with that statement?


jwq wrote: You and the other devs might be able to reproduce the increasing memory use by opening a window (so you have more than one window open) and opening articles in new tabs and then closing the tabs.
Might? Their time is less valuable than yours?

How about you start by explaining your objections to you filing a bug on your problem.
"The only thing necessary for the triumph of evil, is for good men to do nothing." - Edmund Burke (attrib.)
.
Post Reply