debian: mozilla into cgroup limiting memory?

`ulimit -v` doesn't work very well for multithreaded applications to limit their memory usage because it just spawns off more processes when it wants to hog more resources, and any limit I've found to stop it crashing my machine are unrealistically small per process and stops legit tabs from running. How, as an unprivledged user on debian, do I put mozilla into its own cgroup limiting its memory usage to ~ 50% of real memory (16GB ought be enough for 3 tabs these days, eh?). -- Tim Connors

On Fri, Dec 25, 2020 at 02:38:16PM +1100, Tim Connors wrote:
`ulimit -v` doesn't work very well for multithreaded applications to limit their memory usage because it just spawns off more processes when it wants to hog more resources, and any limit I've found to stop it crashing my machine are unrealistically small per process and stops legit tabs from running.
How, as an unprivledged user on debian, do I put mozilla into its own cgroup limiting its memory usage to ~ 50% of real memory (16GB ought be enough for 3 tabs these days, eh?).
firejail might be able to do it, although it seems that its '--rlimit' option has been rermoved. firejail is setuid root so doesn't need sudo. worth looking into, anyway. or there may be other programs which allow control group containerisation for unpriviledged users. another possibility is to run a VM for firefox, and limit the VM's memory. Should work OK for most sites, but badly for sites like youtube that want hardware video acceleration. Dunno if there's any easy way to create a VM as an unprivileged user with KVM but it is possible for root to set one up and allow a user to run it. Virtual Box is intended for use by unpriviledged users. Also, here's a reddit thread on this topic from earlier this year. most of the suggestions require sudo. https://www.reddit.com/r/linuxadmin/comments/fbfc6w/how_to_wrap_my_firefox_p... craig ps: the single best way to reduce browser bloat is to install ublock origin and umatrix (or other ad blocker and javascript controller). fucking ads and shitty javascript are responsible for most browser memory and other resource wastage. for those javascript-encrusted sites that you can't avoid for whatever reason, occasionally killing the tab/window and restarting it can help to regain leaked memory. pps: final alternative: buy more RAM. You owe it to the advertisers and other spies. After all, they're the real owners of your PC. -- craig sanders <cas@taz.net.au>

On Sat, 26 Dec 2020, Craig Sanders via luv-main wrote:
pps: final alternative: buy more RAM. You owe it to the advertisers and other spies. After all, they're the real owners of your PC.
When I bought the laptop in 2014, I thought "32GB would be enough for *anyone*!". But specifically, looking at what trigger it to crash at 2:14PM yesterday -- munin showed swap usage suddenly started to increase at 2am the night before, 3 hours after I went to bed. Swap started from 0bytes usage, and went straight to 10GB usage: http://rather.puzzling.org/munin-cgi/static/dynazoom.html?plugin_name=dirac%... before ramping up to 64GB and crashing. Why do I remember 2:14? Because at 2:15, having finally wiped my bleary eyes clean and having had 2 espressos from my new christmas present, I then proceeded to my laptop and tried to wake up the screen, and ... zip, nadda. The last syslog was at 2:14 - pulseaudio emitting a faint "Daisy, Daisy / Give me your answer, do". By 2:15, not even magic sysrq responded. `atop` ashowed it was one of the millions of "Web Content" helper threads, although the main firefox-esr process was using a healthy 17GB of RSS before it started being forced out at 1:30am. Actually, the whole behaviour is sus-as: firefox-esr ramps from 7GB to 17GB from 00:10 to 1:30 (23GB VSIZE at 1:30), then ramps down while a "Web Content" ramps up at 06:10 to death-do-us-part. Makes me think it was some kind of mozilla-self-update-behind-the-scenes crap. Oddly enough, this is the first time I've used atop to diagnose processes after the fact. But atop stopped logging after the reboot and didn't recover until today's log rotation cronjob. -- Tim Connors

On Saturday, 26 December 2020 2:51:06 PM AEDT Tim Connors via luv-main wrote:
When I bought the laptop in 2014, I thought "32GB would be enough for *anyone*!".
My laptop has 8G of RAM. I run etbe-mon (the monitoring system I forked from Trocki Mon) on it and have it Jabber me when memory use gets excessive. Since doing that I've been able to kill Chrome well before I get an Oom. CGroups is specifically designed to not work as non-root. But you could probably set things up to have a separate UID for that and use sudo or machinectl to run it under that user. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/

On Saturday, 26 December 2020 6:17:27 PM AEDT Keith Bainbridge via luv-main wrote:
On 26/12/20 2:51 pm, Tim Connors via luv-main wrote:
When I bought the laptop in 2014, I thought "32GB would be enough for *anyone*!".
Isn't that what 'they' said when RAM was limited to 1MB
32G seems a lot for just web browsing. I have 100+ tabs open in Chrome and it runs fine in 8G. Software keeps getting bigger to fill all available space. I don't think that KDE now in 8G of RAM is doing anything for me that KDE didn't do for me in 96M in 1999. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
participants (4)
-
Craig Sanders
-
Keith Bainbridge
-
Russell Coker
-
Tim Connors