Unfortunately, I don't have much hard data to present. Ever since I upgraded to Firefox 98, my system's RAM (16G) and swap (2G) get nearly exhausted within a couple of days of starting Firefox. Restarting Firefox releases all the memory as expected and all is well for 2-3 days before the memory consumption gets high enough to cause unnecessary paging. Before the upgrade to v98, I used to run firefox for weeks without *any* issues like this. Normally I use a couple of extensions, but I've reproduced it without any extensions enabled. $ grep firefox /var/log/messages Jan 20 14:23:29 satis pkg[1355]: firefox upgraded: 90.0.1,2 -> 95.0.2_2,2 Mar 19 12:55:28 satis pkg[91791]: firefox upgraded: 95.0.2_2,2 -> 98.0.1,2 Mar 28 22:30:31 satis kernel: pid 4282 (firefox), jid 0, uid 1000, was killed: out of swap space Apr 3 09:31:13 satis pkg[27892]: firefox upgraded: 98.0.1,2 -> 99.0,2 Apr 6 23:13:24 satis kernel: pid 10976 (firefox), jid 0, uid 1000, was killed: out of swap space Apr 10 18:47:58 satis pkg[1460]: firefox upgraded: 99.0,2 -> 99.0_1,2 Apr 16 17:27:15 satis pkg[81292]: firefox upgraded: 99.0_1,2 -> 99.0_2,2 Apr 19 00:04:57 satis kernel: pid 6668 (firefox), jid 0, uid 1000, was killed: out of swap space Apr 19 00:04:59 satis kernel: pid 82135 (firefox), jid 0, uid 1000, was killed: out of swap space Apr 19 00:05:01 satis kernel: pid 7545 (firefox), jid 0, uid 1000, was killed: out of swap space The firefox got killed because it ran the system out of memory on the 19th. I restarted it, and after ~10 hours of mostly idling it was: $ ps aux|egrep '(COMMAND|firefox)' USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND jeffpc 12355 0.1 7.1 11646412 593476 v0 S 09:48 0:18.64 firefox jeffpc 12357 0.0 1.6 287388 129120 v0 I 09:48 0:00.05 /usr/local/lib/firefox/firefox -content jeffpc 12358 0.0 2.0 2532140 168012 v0 I 09:48 0:00.48 /usr/local/lib/firefox/firefox -content jeffpc 12359 0.0 1.9 2522204 159644 v0 I 09:48 0:00.38 /usr/local/lib/firefox/firefox -content jeffpc 12362 0.0 4.6 2956960 381616 v0 S 09:48 0:04.63 /usr/local/lib/firefox/firefox -content jeffpc 12363 0.0 2.9 2794572 238748 v0 S 09:48 0:01.76 /usr/local/lib/firefox/firefox -content jeffpc 12367 0.0 1.8 2506476 148620 v0 I 09:49 0:00.26 /usr/local/lib/firefox/firefox -content jeffpc 12368 0.0 2.5 2567212 204548 v0 S 09:49 0:00.95 /usr/local/lib/firefox/firefox -content jeffpc 12369 0.0 1.9 2516688 160500 v0 S 09:49 0:00.78 /usr/local/lib/firefox/firefox -content jeffpc 12370 0.0 2.0 2526916 163660 v0 I 09:49 0:00.34 /usr/local/lib/firefox/firefox -content jeffpc 12372 0.0 2.1 2533480 176008 v0 S 09:49 0:02.67 /usr/local/lib/firefox/firefox -content jeffpc 12373 0.0 1.8 2503872 145752 v0 I 09:49 0:00.12 /usr/local/lib/firefox/firefox -content jeffpc 12394 0.0 1.8 2503868 146488 v0 I 09:49 0:00.11 /usr/local/lib/firefox/firefox -content jeffpc 12395 0.0 1.8 2503872 146452 v0 I 09:49 0:00.11 /usr/local/lib/firefox/firefox -content jeffpc 12445 0.0 0.0 12868 2016 7 S+ 09:53 0:00.00 egrep (COMMAND|firefox) Another 24 hours later (with some evening/morning browsing and lots of idling during the day/night): $ ps aux|egrep '(COMMAND|firefox)' USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND jeffpc 12355 0.6 12.5 12928316 1039292 v0 S 09:48 20:39.08 firefox jeffpc 17248 0.2 7.6 3500156 633440 v0 S 20:29 7:34.43 /usr/local/lib/firefox/firefox -conten jeffpc 17436 0.2 6.5 3633244 541748 v0 S 20:54 8:38.38 /usr/local/lib/firefox/firefox -conten jeffpc 16833 0.1 5.5 3447880 460024 v0 R 19:35 5:51.86 /usr/local/lib/firefox/firefox -conten jeffpc 12357 0.0 1.1 287516 94092 v0 I 09:48 0:00.10 /usr/local/lib/firefox/firefox -conten jeffpc 12358 0.0 1.7 2616232 143672 v0 I 09:48 0:06.67 /usr/local/lib/firefox/firefox -conten jeffpc 12359 0.0 1.4 2529100 112988 v0 I 09:48 0:01.75 /usr/local/lib/firefox/firefox -conten jeffpc 12362 0.0 6.5 3359912 537288 v0 S 09:48 4:46.52 /usr/local/lib/firefox/firefox -conten jeffpc 12363 0.0 2.7 3064288 226496 v0 S 09:48 2:10.52 /usr/local/lib/firefox/firefox -conten jeffpc 12367 0.0 1.4 2525440 113836 v0 S 09:49 0:04.57 /usr/local/lib/firefox/firefox -conten ...20 lines omitted... jeffpc 23084 0.0 1.6 2523704 135192 v0 S 08:49 0:01.00 /usr/local/lib/firefox/firefox -conten jeffpc 23085 0.0 1.5 2506320 125904 v0 S 08:49 0:00.56 /usr/local/lib/firefox/firefox -conten jeffpc 23086 0.0 1.5 2505404 125068 v0 S 08:49 0:00.53 /usr/local/lib/firefox/firefox -conten jeffpc 23087 0.0 1.7 2551240 140020 v0 S 08:49 0:00.89 /usr/local/lib/firefox/firefox -conten jeffpc 23088 0.0 1.5 2505272 124888 v0 S 08:49 0:00.50 /usr/local/lib/firefox/firefox -conten jeffpc 23099 0.0 4.8 2904628 396040 v0 S 08:50 0:35.20 /usr/local/lib/firefox/firefox -conten jeffpc 23109 0.0 1.5 2503872 122596 v0 I 08:51 0:00.27 /usr/local/lib/firefox/firefox -conten jeffpc 23205 0.0 1.5 2503872 126068 v0 S 08:59 0:00.27 /usr/local/lib/firefox/firefox -conten jeffpc 23236 0.0 1.5 2503872 126860 v0 I 09:02 0:00.18 /usr/local/lib/firefox/firefox -conten jeffpc 23253 0.0 0.0 12868 1932 7 S+ 09:04 0:00.00 egrep (COMMAND|firefox) What the ps(1) output doesn't show is that the virtual size of one of the processes seems to climb to as high as 25GB when actively browsing the web but quickly drop back down to "reasonable" single digit GB. Let me know what other information I should collect or what I should try to get to the bottom of this.
Packages from latest or quarterly? pkg -vv | grep -e url -e enabled Which version of FreeBSD, exactly? freebsd-version -kru ; uname -aKU Is there discussion anywhere else? (In reply to Josef 'Jeff' Sipek from comment #0) > … reproduced it without any extensions enabled. … With Firefox in safe mode, or by disabling the extensions in normal mode? > … virtual size of one of the processes seems to climb to as high as 25GB … Aim to identify the site, or page, with which this occurs. about:memory
> Packages from latest or quarterly? Latest: url : "pkg+http://pkg.FreeBSD.org/FreeBSD:13:amd64/latest", > Which version of FreeBSD, exactly? $ freebsd-version -kru ; uname -aKU 13.0-RELEASE-p11 13.0-RELEASE-p11 13.0-RELEASE-p11 FreeBSD satis 13.0-RELEASE-p11 FreeBSD 13.0-RELEASE-p11 #0: Tue Apr 5 18:54:35 UTC 2022 root@amd64-builder.daemonology.net:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 1300139 1300139 > Is there discussion anywhere else? None that I'm aware of. > (In reply to Josef 'Jeff' Sipek from comment #0) > > … reproduced it without any extensions enabled. … > > With Firefox in safe mode, or by disabling the extensions in normal mode? Disabling in normal mode. > > … virtual size of one of the processes seems to climb to as high as 25GB … > > Aim to identify the site, or page, with which this occurs. Pretty much every page make the virtual size spike up. Not necessarily to 25GB, but it is relatively common. Just now, the "main" process has 13GB virt / 1.1GB rss. I opened a new tab, and the virtual size jumped to 19GB. Closing the tab and opening a new tab again, didn't do it. Waiting 20 minutes and opening a new tab did it again. > about:memory I have no idea how to read this or what to look for. FWIW, it says: WARNING: the 'heap-allocated' memory reporter does not work for this platform and/or configuration. This means that 'heap-unclassified' is not shown and the 'explicit' tree shows less memory than it should.
(In reply to Josef 'Jeff' Sipek from comment #2) Despite the shortcomings, about:memory may help to identify the site, or page, that's causing excessive use of memory. When you sense excessive use, click each item under the process index. Is any one using an extraordinarily large amount of memory? Here, for example, I have one item that clearly uses around seven times as much as any other. Not a bug, in my case … … in your case, maybe you'll find something that uses much more than 7x what's used by other things.
Sorry for the delay. I about mid-way through my multi-day data "collection", I upgraded to firefox 100 and so I wanted to give it enough time to see what it behaves like. Observations: * Firefox 100 seems a little better than 99 * The memory usage growth seems to be a function of how many (not which) websites I visit. "Vigorous" browsing will run up the process size much faster than more casual browsing. * Having approximately 20 firefox ~150-380MB processes mostly idle along with the 1.4GB main process chews up about 1/3 of the system RAM. * The main process is the major memory hog - the other processes, while not lightweight, tend to be more reasonable. * The about:memory output doesn't show anything that jumps out at me (aside from the ridiculous vsize/resident and max vsize/resident values). Is there a way to tell firefox that even though the machine has 16GB, I'd like to keep some memory for the ARC, kernel, and other processes? Main process's about:memory headings & summary: 563.47 MB (100.0%) -- explicit ├──364.26 MB (64.65%) -- gfx 16.18 MB (100.0%) -- decommitted 6,172 (100.0%) -- event-counts 16 (100.0%) -- extensions 379.84 MB (100.0%) -- gfx 4.35 MB (100.0%) -- images 249 (100.0%) -- ipc-channels 285 (100.0%) -- ipc-channels-peak 502 (100.0%) -- js-component-loader 4 (100.0%) -- js-helper-threads 90.11 MB (100.0%) -- js-main-runtime 33.00 MB (100.0%) -- js-main-runtime-gc-heap-committed 22 (100.0%) -- js-main-runtime-realms 58 (100.0%) -- message-manager 1,973 (100.0%) -- observer-service 747 (100.0%) -- observer-service-suspect 674 (100.0%) -- preference-service 0 (100.0%) -- queued-ipc-messages 0.14 MB (100.0%) -- shared-string-bundles 7.77 MB (100.0%) -- window-objects 1.50 MB ── font-list-shmem 2.18 MB ── gfx-surface-image 0.00 MB ── gfx-textures 0.00 MB ── gfx-textures-peak 0.00 MB ── gfx-tiles-waste 0 ── ghost-windows 3 ── imagelib-surface-cache-already-present-count 0.58 MB ── imagelib-surface-cache-estimated-locked 0.64 MB ── imagelib-surface-cache-estimated-total 146 ── imagelib-surface-cache-image-count 174 ── imagelib-surface-cache-image-surface-count 94 ── imagelib-surface-cache-locked-image-count 115 ── imagelib-surface-cache-locked-surfaces-count 0 ── imagelib-surface-cache-overflow-count 0 ── imagelib-surface-cache-table-failure-count 59 ── imagelib-surface-cache-tracked-cost-count 59 ── imagelib-surface-cache-tracked-expiry-count 0 ── imagelib-surface-cache-tracking-failure-count 2.06 MB ── js-main-runtime-temporary-peak 4,992 ── page-faults-hard 13,369,887 ── page-faults-soft 1,710.35 MB ── private 1,362.16 MB ── resident 1,448.52 MB ── resident-peak 2.04 MB ── shmem-allocated 126.62 MB ── shmem-mapped 0 ── unresolved-ipc-responses 20,886.48 MB ── vsize 8,191.63 MB ── vsize-max-contiguous 0.00 MB ── wasm-runtime
You can try to start Firefox like this: limits -m 4g firefox
(In reply to Lena from comment #5) Interesting idea to use limits. Setting the limit to 4GB works to keep the *sum* of all the firefox processes' resident sizes under 4GB, but the main process's resident size is slowly growing (as before). So, while 2 days ago (shortly after restarting firefox) the main process accounted for ~750MB (~18% of 4GB) now it is 1560MB (38%). As a result, firefox keeps fewer process alive as time goes by. I don't know if it will stop growing at some point, but if it doesn't the main process will hit the 4GB limit on its own. :) Oh, and the virtual size of the main process is still ridiculous 13GB, but I suppose that doesn't matter that much. (Yes, I'm making a few assumptions about firefox's memory usage and FreeBSD kernel's handling of memory in that statement.)