There’s also the idea that free RAM is somehow a good thing. In an ideal system, the RAM would always be “full” of potentially useful data. Having a bunch of empty RAM means that it’s not being useful. That space could be used to hold plenty of regularly used files that would be instantly loaded instead of having to pull from the drive again.
I don’t know when everyone started getting concerned with RAM usage, but in a perfect system, it would hold onto all of your frequently used programs and files that it could fit from boot and then those would load instantly.
Some Linux distros even allow loading the entire OS into RAM for wild speeds.
Idle RAM is just that. It does you no favors. Now, I do understand that you don’t want to be completely out, but we act like having 80% free is a goal for some reason.
The problem is that the extra RAM used by a browser is held on an exclusive basis and so is not nicely reclaimable by the kernel. I love that Linux caches the shit out of files in RAM, it’s great. It’s also great that it can release that memory when I launch a chundering dumpster fire application that eats all of my RAM. If a browser had been holding that memory, then the godawful Linux OOM killer would have launched, halted all threads on the system, walked the entire process tree, and SIGKILLed something (probably not a browser tab) before letting everyone else resume.
With the way memory is currently managed, a bloated browser is a liability. Cached state needs to be stored in something like a mmaped file so that the kernel can flush pages out of memory if someone else comes along with a malloc. Alternatively, there needs to be communication between a browser and a userspace OOM daemon. If the system started hitting a soft limit, then the browser could start unloading background shit more aggressively.
Free memory is wasted memory, but so is memory that can’t be used for anything else when it’s needed.
Yeah, I agree. Browsers all seemed to act like they are the only thing running on the computer at some point, practically resembling their own OS with the amount of containerization and complexity. There should definitely be a way for the OS to request some RAM be released from the browser.
That’s why I just prefer to limit the RAM available to the browser to an amount that I feel is necessary for good performance while not so much that it causes issues with other things running. To some people that might sound like a bad or stupid idea but think of it this way. You just said that modern browsers are complex and resemble their own Operating System, right? Well if you were running a VM you probably wouldn’t give the virtualized OS complete access to all your RAM, that’s asking for the VM to crash or freeze your PC.
So why should general practice be any different for a browser then, they may be less aggressive than a Kernel managed VM but they can still be problematic when they eat to much RAM. Which is why I choose to limit mine so it doesn’t get more than 8GB, which I feel is perfectly reasonable on most systems where that’s half of all the memory available, and even on bigger ones you’re not missing out on much. Firefox performs just as well with 8GB as it does with 16GB, but with 16GB it’ll eat way more than it uses.
Here’s the script I used. Should work for most linux users. I don’t know how to do it on Windows since I don’t use Browsers there for long enough periods for this to become problematic.\
Having programs steal or sit on RAM without using it is never a good thing. That’s why it’s called a memory leak, because it’s as if the free memory is leaking away. And it gets deprived from other apps that might need it more than Firefox or chromium does.
Your idea only works if programs actually take only as much ram as they need and give it back when done, but they don’t do that, they usually sit on it until it’s pried from their cold dead fingers. That’s what memory leaks are, and modern browsers these days are extremely prone to them.
Unused RAM is wasted RAM. It consumes the exact same amount of power whether there’s useful data in it or not. Any self-respecting operating system will fill up RAM that applications aren’t using with frequently accessed files, so they’re ready to go in an instant.
I think that’s precisely why limiting RAM on apps like Chrome or Firefox is so necessary, these apps never release their RAM when they are supposed to, they hoard anything that isn’t free and don’t give back when it’s needed, which is why in the reply to the top comment I shared a desktop entry to limit RAM on Firefox or whatever app you so choose.
Oh, I totally agree. Being afraid to call out to the allocator because “hey, I might need that memory later” is kinda not great. To a certain extent I can see how if an application tends to thrash memory, making a kajillion syscalls might hurt performance, enough that on many machines the gains from doing a single big allocation on the system and then slicing it up into small allocations in-process might outweigh the downsides, but still…
There’s also the idea that free RAM is somehow a good thing. In an ideal system, the RAM would always be “full” of potentially useful data. Having a bunch of empty RAM means that it’s not being useful. That space could be used to hold plenty of regularly used files that would be instantly loaded instead of having to pull from the drive again.
I don’t know when everyone started getting concerned with RAM usage, but in a perfect system, it would hold onto all of your frequently used programs and files that it could fit from boot and then those would load instantly.
Some Linux distros even allow loading the entire OS into RAM for wild speeds.
Idle RAM is just that. It does you no favors. Now, I do understand that you don’t want to be completely out, but we act like having 80% free is a goal for some reason.
The problem is that the extra RAM used by a browser is held on an exclusive basis and so is not nicely reclaimable by the kernel. I love that Linux caches the shit out of files in RAM, it’s great. It’s also great that it can release that memory when I launch a chundering dumpster fire application that eats all of my RAM. If a browser had been holding that memory, then the godawful Linux OOM killer would have launched, halted all threads on the system, walked the entire process tree, and SIGKILLed something (probably not a browser tab) before letting everyone else resume.
With the way memory is currently managed, a bloated browser is a liability. Cached state needs to be stored in something like a
mmaped file so that the kernel can flush pages out of memory if someone else comes along with amalloc. Alternatively, there needs to be communication between a browser and a userspace OOM daemon. If the system started hitting a soft limit, then the browser could start unloading background shit more aggressively.Free memory is wasted memory, but so is memory that can’t be used for anything else when it’s needed.
Yeah, I agree. Browsers all seemed to act like they are the only thing running on the computer at some point, practically resembling their own OS with the amount of containerization and complexity. There should definitely be a way for the OS to request some RAM be released from the browser.
That’s why I just prefer to limit the RAM available to the browser to an amount that I feel is necessary for good performance while not so much that it causes issues with other things running. To some people that might sound like a bad or stupid idea but think of it this way. You just said that modern browsers are complex and resemble their own Operating System, right? Well if you were running a VM you probably wouldn’t give the virtualized OS complete access to all your RAM, that’s asking for the VM to crash or freeze your PC. So why should general practice be any different for a browser then, they may be less aggressive than a Kernel managed VM but they can still be problematic when they eat to much RAM. Which is why I choose to limit mine so it doesn’t get more than 8GB, which I feel is perfectly reasonable on most systems where that’s half of all the memory available, and even on bigger ones you’re not missing out on much. Firefox performs just as well with 8GB as it does with 16GB, but with 16GB it’ll eat way more than it uses.
Here’s the script I used. Should work for most linux users. I don’t know how to do it on Windows since I don’t use Browsers there for long enough periods for this to become problematic.\
Desktop file to limit Firefox to 8GB of RAM
[Desktop Entry] Version=1.0 Name=Firefox RAM limit 8GB GenericName=Firefox Ram limit 8GB Comment=Limit RAM for Firefox to 8GB; Exec=systemd-run --user --scope -p MemoryLimit=8G firefox Icon=firefox Type=Application Terminal=false Categories=Utility;Development; StartupWMClass=Firefox
CC: @[email protected]
Having programs steal or sit on RAM without using it is never a good thing. That’s why it’s called a memory leak, because it’s as if the free memory is leaking away. And it gets deprived from other apps that might need it more than Firefox or chromium does.
Your idea only works if programs actually take only as much ram as they need and give it back when done, but they don’t do that, they usually sit on it until it’s pried from their cold dead fingers. That’s what memory leaks are, and modern browsers these days are extremely prone to them.
Unused RAM is wasted RAM. It consumes the exact same amount of power whether there’s useful data in it or not. Any self-respecting operating system will fill up RAM that applications aren’t using with frequently accessed files, so they’re ready to go in an instant.
I think that’s precisely why limiting RAM on apps like Chrome or Firefox is so necessary, these apps never release their RAM when they are supposed to, they hoard anything that isn’t free and don’t give back when it’s needed, which is why in the reply to the top comment I shared a desktop entry to limit RAM on Firefox or whatever app you so choose.
Oh, I totally agree. Being afraid to call out to the allocator because “hey, I might need that memory later” is kinda not great. To a certain extent I can see how if an application tends to thrash memory, making a kajillion syscalls might hurt performance, enough that on many machines the gains from doing a single big allocation on the system and then slicing it up into small allocations in-process might outweigh the downsides, but still…