I think there is some sort of memory-leak happening with this version of Firefox. Or it’s one of 100000 tabs that I have open behaving really bad
I mean like normally I literally have like 1000+ tabs open because I dont like bookmarking and it’s like backlog of sorts… what to watch and go through. And it’s fine and stable for weeks… firefox consuming like ~16GB out of 32GB memory and it’s stable there with small fluctuations. But now when I open firefox it starts there… and then it ramps up GPU usage to 70%+ and GPU memory (24GB I think … on 7900xtx) fills up rather rapidly in minutes and then the remaining system memory fills up in minutes and then earlyoom kills firefox. And then I have no processes or apps visibly consuming any memory, yes I have like 20GB of memory full and unrecoverable without reboot. It’s like something is consuming it or keeping it locked, but no idea what. After reboot down to like 1-1.5GB on RAM usage and everything works fine. Until I try to reopen Firefox.
Now downgraded to 147.0.2 and same stuff happens… so I think it’s some website gone really bad. And firefox just lets it happen without limiting it?
Mod edit: corrected downgraded Firefox version from 173 to 147 (firefox v147 is the version currently in Manjaro’s repos)
Just this version? … … maybe @Aragorn’s command may help, after dealing with that rogue website of course:
su -c "sync && echo 3 > /proc/sys/vm/drop_caches"
… I actually added that as an alias to my ~/.bashrc some time back (not the recommended way, one is supposed to use a separate file, but it’s fine for me):
alias dropcache='su -c "sync && echo 3 > /proc/sys/vm/drop_caches"'
It’s an alias in my bash configuration as well. I use it every day anyway, so it saves me from having to type up the whole thing by hand every time.
Copycat! That’s how I called it on my system. Have you been looking over my shoulder again?
Well, your ~/.bashrc isn’t very likely to get overwritten — an update does not (and may not ever) touch anything in the users’ home directories — but, yes, for the sake of good housekeeping, it is best to put your aliases in a separate file and source it from within ~/.bashrc.
Personally, I’ve made it even simpler — or more convoluted, depending on how you look at it — and I have only one extra line in my ~/.bashrc, which sources my ~/.bash_custom file, and that one then in turn sources both my ~/.bash_aliases and ~/.bash_functions.
It is actually simpler because it only adds a single line to the original vanilla ~/.bashrc.
Seems to me like you could use a couple of very handy firefox extensions:
The first will unload from memory tabs which have not been visited recently, freeing up RAM, after a set time. It retains the tab title, URL etc - just unloads the page content:
The second is for if you ever decide that you have too many tabs open & want to close them but don’t want to lose them. You can save the tabs as sessions that can be restored later:
Of course, you should make sure that you set the add-on’s preferences to use “Lazy Loading” when restoring a session so that restored tabs are not all reloaded at the same time.
I’ve been using both of the above for years - they’re very reliable.
If you have a lot of tabs open for a site that is refreshing parts of the page in the background, then that could be the cause. It could be as simple as a site recently adding videos which are pre-loading in the background to its pages. I guess firefox might not be picking up the effect on your system’s memory due to it running each tab as a separate process. Often Firefox will provide a notification at the top of a page if it is slowing things down so that the user can stop it from loading. But if that is happening on tabs other than the active tab, then you may not be aware they are causing problems.
Check browser.tabs.unloadOnLowMemory in about:config. If set to false, change to true and should automatically unload inactive tabs after the milliseconds set in browser.tabs.min_inactive_duration_before_unload to avoid memory issues.
The problem wasn’t exactly “multiple tabs” or “something weird happening in the background tab”, but “one website (tradingview dot com) acting very bad in Firefox” in active window/tab (I have like ~15 firefox windows open with 5-50 tabs open in each … thematically sorted between windows).
The “band-aid” solution was to figuring out which tab was the problematic one and then closing it. (And opening it with Brave, where it behaved very nicely.)
Alternate “real real” solution would have been something that manages to put some memory cap for tabs globally. Like no single firefox tab can consume more than 1GB of memory any time and if it does, then stop or unload it or something. Most don’t need more than 50-200MB anyway… but when something goes haywire, then there is some limiter in place… before earlyoom kicks in and kills the entire browser.
But thank you all for suggesting several different ways to handle all the background tabs and jeeting them out of memory to save memory… which is nice also
(
additionally to above mentioned tricks, additional things to consider while tackling “the Firefox taking too much memory problem”
dom.ipc.processCount at 4 was much better than 8 (that I had by default).
addons:
Duplicate tabs closer – because you really don’t need several copies of the same url open usually.
uBlock origin – probably the best adblocker
)
I haven’t experienced any issues with firefox v147 on Wayland so far. Although my setup is probably very different to yours, as I run Firefox completely in RAM (including the cache), and rarely have more than 30 tabs open at a time. However, last night I did have 200+ tabs open for a few hours, but I saved them as a separate session to revisit later, and closed those tabs before closing Firefox.
And, as I mentioned earlier, I unload tabs from memory automatically if they haven’t been activated in the last 10 minutes.
If the issue has only started occurring from v147, then maybe looking through the release notes for all 4 releases (so far) of firefox v147 might help you to work out what change since v146 is possibly contributing to the issue:
Or actually found the real problem nr.2 – current HDR implementation in Firefox.
So to run it stable in the real Wayland mode, I have to turn in about:config gfx.wayland.hdr to false and it’s also totally stable so far for almost a day.
Your assumption is correct. gfx.wayland.hdr in my Firefox configuration is set to false.
I’ll edit the thread title to reflect that it relates to HDR on Firefox, as that may help others who encounter a similar issue. And I think your post can now be marked as the solution, as the original solution was only a workaround that had to be manually run whenever the RAM started getting full.
Yes and no. Tbh it’s like multiple problems at once situation. The original problem with tradingview website was another issue with memory leak. The HDR issue with Wayland is not related to the memory issue at all, but still an issue.
… maybe 
