Firefox consumes all memory

hsw

hsw

After running Firefox for a few days almost all of the memory becomes wired and the machine begins swapping and becomes very slow.
If I am able to get to a terminal and kill Firefox the Wired memory does not get released. Any attempt to restart Firefox tends to result in a freeze.
Later check of /var/log/messages showing programs terminated and get swap failures.

Similar symptoms occur on a second system but that is running Chromium Browser. I have stopped the Jail running Chromium and the system
seems to be better.

Any suggestions as to what to check when the system is about to run out of memory to figure out if stopping Firefox/Chromium has released memory or not?
 
I use graphics/gimp on such a frequent basis I usually don't close it. After several days and gads of graphic images manipulated I saw more swap in use than I ever had in all the time I've use FreeBSD. 68% with 2914M memory free on FreeBSD 12.2-RELEASE-p7:
swap68inuse.png

I shut down Gimp and it was slowly all freed uo, came back and settled at 3%, which is about normal if it uses any.
Right now it's not using any on the same machine with 733M memory free.

www/firefpc-esr is never a problem in that area for me.
 
Any subscription or other "extras" on Firefox? Or open pages like Youtube or something with javascript running all time? If you close all tabs and FF remain open, is the result the same?
 
There is a lot running, like Slack and other JS heavy sites. Closing Firefox does not appear to help the Wired Memory stays

Just after after todays reboot:
Code: 
Mem: 238M Active, 486M Inact, 1265M Wired, 19G Free

10 hours later:
Code: 
% top -n 5 -o size ; vmstat
last pid: 16377;  load averages:  0.44,  0.54,  0.59; battery: 100%  up 0+10:23:21    19:51:35
141 processes: 1 running, 140 sleeping
CPU:  4.7% user,  0.0% nice,  0.9% system,  0.1% interrupt, 94.3% idle
Mem: 2607M Active, 9896M Inact, 715M Laundry, 3360M Wired, 5140M Free
ARC: 2036M Total, 844M MFU, 981M MRU, 1605K Anon, 15M Header, 190M Other
     1540M Compressed, 2997M Uncompressed, 1.95:1 Ratio
Swap: 4096M Total, 4096M Free

  PID USERNAME    THR PRI NICE   SIZE    RES STATE    C   TIME    WCPU COMMAND
 4265 hsw          29  20    0    28G  1076M select   7  12:10   0.20% firefox
 4259 hsw         154  21    0  9923M  2873M select   4  53:09   2.05% firefox
 4261 hsw          36  20    0  8132M  1836M select   0  15:35   0.00% firefox
 4402 hsw          36  20    0  4310M  1385M select   6   5:19   0.20% firefox
 7416 hsw          36  21    0  3825M  1015M select   0  19:21   1.66% firefox

 procs    memory    page                      disks     faults       cpu
 r  b  w  avm  fre  flt  re  pi  po   fr   sr nv0 ad0   in   sy   cs us sy id
 0 14  0  83G 5.0G 3.4K   0   1   0 3.0K 1.0K   0   0  224  14K 6.4K  5  1 94
 
hsw said:
After running Firefox for a few days almost all of the memory becomes wired and the machine begins swapping and becomes very slow.
[...]
Click to expand...

I realise my experience is mainly on Windows but I assume that the firefox code base (esp. memory usage algorithm) doesn't differ that much across OS-s; YMMV. My apologies for injecting this here mainly from a non-FreeBSD perspective. I have firefox-esr on FreeBSD but that is not my daily driver.

Note: continuous use of a firefox window with multiple tabs open, but also with closed tabs, will result in a growing memory footprint: all those closed tabs and their history are being stored/retained in some form. Closing a window with a heavy tab history almost certainly does not result in (fully) releasing the memory belonging to that particular firefox window and its history; in windows CTRL+SHIFT+N reopens a closed firefox window with all of its history. Closing that particular firefox window and then killing firefox alltogether does get rid of it. A subsequent firefox restart leaves that baggage behind. I use firefox with the setting that when it restarts it opens with all the windows & tabs with which it closed.

Using daily firefox (std. version) and firefox-esr (both on Windows 10) with multiple windows and tabs open at the same time. As for some months both versions seem to be prone to gulp up more and more memory (laptop 16GB, i7-6700HQ). Seeming especially present in firefox std.; there seems to be some unexplainable cause (at least to me) for that memory hunger. Sometimes (by killing firefox from the task manager) a restart helps to set a more realistic memory footprint and curb that hunger.

Also, it seems that when there is another program claiming much physical memory (i.e. firefox std. & firefox-esr running in parallel) to the max. (in my case 16GB) the tendency to gulp up memory seems to be somewhat constrained. Although it's definitely no fun when total claimed/used memory gets above 94%; for some 6 months having a growing tendency to gulp up more and more processor cycles as well. There are certain sites/pages that seem to "incite" firefox to claim more memory; possibly by more heavier javascript activity, youtube comes to mind and yahoo news. In my experience, killing and restarting firefox with several yahoo pages results in a consistent big memory footprint. Having said that, there are also times that a current firefox instantiation gulps up a sizable amount of ram (say > 8 GB) and after killing & restarting it, it lives happily for quite some time with a more normal memory footprint, as in < 5GB.

Firefox-esr, as stated above, is somewhat less prone to multiple .x version updates in rapid succession—a little less fad/gadget-driven? Lately, I tend to postpone an update to the next major version until at least one minor update is available (unless security issues indicate otherwise).
 
In short - browsers are tragedy. 10 years ago, javascript was still security "hole" and it was recommended to disable it for higher security. With time it become mandatory for most sites and cannot be disabled. In addition Google ads inject their javascript connected to external servers (usually slower than main site). The result is 99% memory usage and 99% CPU - for browsing which is waste of time in many cases. And finally most software developers say "web/js UI is the future".
 
6502 said:
The result is 99% memory usage and 99% CPU - for browsing which is waste of time in many cases.
Click to expand...
No it doesn't.


eternal_noob said:
Sane web developers avoid JS wherever they can.
Click to expand...

No we don't. But sane developers use as little as necessary to accomplish the task. Unfortunately, everything is market driven just like the drivel on TV. So sites need their flash, bang, gee whiz looks to showcase their latest products to the unwashed masses who soak it all up and consider it normal.
 
eternal_noob said:
We do.


That's what i meant with "It's the customers who want this sh*t."

* Pagination is sooo 1990, make it infinite scroll *
Click to expand...
Back in the 1980s writing report generators in COBOL, getting page N of M was really difficult; I used a two pass process
just to get the numbering right. I think that minicomputer only had 512Kx16 memory and a 100MB of disks.

Now Firefox is consuming an extra GB or two every day (probably for the emojis ?)

Code: 
last pid: 59893;  load averages:  0.89,  0.90,  0.76; battery: 100%  up 1+00:04:56    09:33:10
141 processes: 1 running, 140 sleeping
CPU:  4.3% user,  0.0% nice,  0.9% system,  0.0% interrupt, 94.8% idle
Mem: 3249M Active, 11G Inact, 811M Laundry, 4128M Wired, 2597M Free
ARC: 1788M Total, 987M MFU, 564M MRU, 3060K Anon, 19M Header, 214M Other
     1328M Compressed, 2239M Uncompressed, 1.69:1 Ratio
Swap: 4096M Total, 4096M Free

  PID USERNAME    THR PRI NICE   SIZE    RES STATE    C   TIME    WCPU COMMAND
 4265 hsw          29  20    0    28G  1112M select   5  18:54   3.17% firefox
 4259 hsw         153  22    0    10G  3033M select   5  96:40   8.30% firefox
 4261 hsw          36  20    0  8160M  1866M select   5  21:24   0.00% firefox
 7530 hsw          30  20    0  6300M  1747M select   6   4:34   0.10% firefox
 4402 hsw          35  20    0  4334M  1444M select   4  11:12   0.10% firefox

 procs    memory    page                      disks     faults       cpu
 r  b  w  avm  fre  flt  re  pi  po   fr   sr nv0 ad0   in   sy   cs us sy id
 0 14  0  85G 2.5G 2.7K   0   0   0 2.5K 1.1K   0   0  150  12K 5.4K  4  1 95
 
I started using www/firefox-esr not too long after www/firefox integrated Quantum Strangeness into its newest version. I compared the two on different machines and Firefox crashed 2-3 times in as many hours when Firefox-ESR hadn't crashed once.

Since then Firefox-ESR has gone Quantum, it's a groovy buzzword, but never went back to Firefox. www/firefox, IMO, is to FreeBSD STABLE as ww/firefox-esr is to FreeBSD RELEASE. They work the bugs out in Firefox then port it over to Firefox-ESR.

drhowarddrfine said:
No we don't. But sane developers use as little as necessary to accomplish the task.
Click to expand...
Admittedly, site layout is not my strong point, and why I liked Frames so much. It gave me a framework to work within.

But I don't use any scripting on my sites. Only valid XHTML 1.0 Transitional and CSS level 3 + SVG to do the job. Sloppy as some might see using Transitional, it's valid as far as W3C is concerned and that is First and Foremost as far as I'm concerned.

I would not have a page on my sites that did not first pass W3C validation (It isn't even considered to be XHTML unless it's valid XHTML.) and have buttons at the bottom of each and every page to check XHTML and CSS validation independently.
 
I learned to write it in 1999. :cool:

Some of that stuff I pulled off archive.org and was done in XHTML 1.0 Strict, I changed the DOCTYPE to Transitional. I can copy the bulk of the markup off what I've written that far back and add new to it.
And if I've written something once I don't write it twice.

Did I mention that I could not only write XHTML, CSS, XML and AIML but 3DML as well?

Or that I had a site for what I'd written done in valid XHTML 1.0 Frameset?
viva_la_validation.jpg
Only the index.html page is Frameset. The rest are regular XHTML pages that go into the frames, but the site checks as Frameset.

If that freaked you out, take a look at the next to last word in the "keyword" metatag of my validated markup:
frameset.jpg
 
Trihexagonal said:
Is that your opinion or worms hanging out your mouth?
Click to expand...
It's the opinion of people who code HTML for a living. Not necessarily my own. But i agree.
Seriously, don't use XHTML Transitional and don't use framesets. THINK OF THE DEAD KITTENS!

Strict is considered better for encouraging more accessible XHTML and better separation of content and presentation.
 
hsw said:

Firefox consumes all memory​

… kill Firefox the Wired memory does not get released. …
Click to expand...

hsw said:
… Closing Firefox does not appear to help …
Click to expand...

So, consider the possibility that Firefox is not a root cause of subsequent problems.

Which version, exactly, of FreeBSD?

Which version of Firefox?

I run Firefox for extended periods without difficulty. Session sizes recently are more than 900 tabs, although the majority are not loaded (I use Simple Tab Groups). When I last counted, more than a hundred extensions enabled.

6502 said:
… "extras" on Firefox? …
Click to expand...

hsw please share a list of enabled extensions. Just the names please; Add-on List-o-matic 9000 will help.
 
hsw said:
After running Firefox for a few days almost all of the memory becomes wired
Click to expand...
This has nothing to do with each other. See my wired memory short after boot (for no reason I would know of):

Code: 
last pid: 12301;  load averages:  1.16,  2.26,  3.21    up 0+01:44:18  05:45:40
67 processes:  1 running, 66 sleeping
CPU:  0.5% user,  0.0% nice,  0.2% system,  0.1% interrupt, 99.2% idle
Mem: 1597M Active, 1727M Inact, 67M Laundry, 14G Wired, 263M Buf, 14G Free
ARC: 4042M Total, 2576M MFU, 1275M MRU, 238K Anon, 36M Header, 154M Other
     2942M Compressed, 4703M Uncompressed, 1.60:1 Ratio
Swap: 20G Total, 20G Free

  PID USERNAME    THR PRI NICE   SIZE    RES STATE    C   TIME    WCPU COMMAND
 7580 pmc          47  22    0  2949M   584M select  18   3:43   9.05% firefox
 7577 pmc          98  21    0  2994M   531M select  18   2:43   1.94% firefox

The wired memory is (mostly) kernel business, it grows happily when it can, but should (slowly) shrink again when memory becomes scarce. Yours looks quite normal.
But your firefox appears to suffer from obesity.

In the preferences of firefox is a setting how many cores it may use. By default it uses all of them. You can reduce that and see if it hurts your performace, it will also reduce the memory consumption.
 
The screenshot I just posted of my W520 FreeBSD 12.1-RELEASE-p3 .mp3 player with top running shows 1133M wired at 120 days uptime, which is pretty close to his. I never turn off any of the apps shown running.
 
Erichans said:
… my experience is mainly on Windows … continuous use of a firefox window with multiple tabs open, but also with closed tabs, will result in a growing memory footprint: …
Click to expand...

Growing endlessly?

If so: I don't find this with Firefox 91.0.1,2 on FreeBSD 14.0-CURRENT c9f833abf1d.

After running for a few hours (I don't know how to interpret the 23:35 in the first screenshot below):
1629698939055.png

– then four more windows (including sign-ins to app.element.io, discord.com and teams.microsoft.com):
1629699039469.png

I'm accustomed to finding one child process with a relatively huge VIRT measurement. Not a problem, just measurably huge. I wonder why there's no such process today.

Compare with a random shot from a few months ago (Firefox 85.0.1), a 23.1 G measurement for one of the child processes:

1629699588946.png
 
You must log in or register to reply here.
Back
Top