[ugjka@archee ~]$ tree /etc/systemd/system.control/
/etc/systemd/system.control/
├── system.slice.d
│ ├── 50-MemoryAccounting.conf
│ └── 50-MemoryLimit.conf
└── user.slice.d
├── 50-MemoryAccounting.conf
└── 50-MemoryLimit.conf
2 directories, 4 files
systemctl set-property user.slice MemoryAccounting=true systemctl set-property user.slice MemoryLimit=5G
No, no, no.
When prompting such commands, you need to be consistent, explain how to restore default settings. Someone can use them, and in a week they will have no idea why his system is behaving strangely.
Suggest them in safe form.
systemctl --runtime set-property user.slice MemoryAccounting=true
systemctl --runtime set-property user.slice MemoryLimit=5G
systemctl set-property user.slice MemoryAccounting=true
systemctl set-property user.slice MemoryLimit=5G
You can also limit system.slice if you run a lot of memory hungry services. You can go granular and set limits for each systemd service.
If that's not your cup of tea then you can just limit Firefox itself: https://www.digitalocean.com/community/ … n-centos-6
You can inspect cgroups memory usage with systemd-cgtop -m.
Learn more about cgroups they are very porwerful
]]>I have conky and it updates every second. It shows the list of the 6 projects that use more RAM. As I have lots of Firefox windows and tabs open, usually 5 of the top 6 projects belog to Firefox, the top one called Firefox (about 13%) and 4 others named "Web Content".
When the problem manifested the top Firefox process would increase RAM consumption very fast (over 2 - 3 seconds) to 50% and then conky would stop updating and the whole desktop would freeze for a few minutes. But after some wait I could kill the Firefox project either with a terminal or with a keyboard shortcut that I configured to kill Firefox.
As I said above it is not manifesting any more. At some stage I checked the Mozilla bugzilla to see if there was anything about this and could not find. However there is a separate post about Firefox freeze by ktatar156 in this forum and what he describes might be the same issue as mine.
]]>But then the problem disappeared without me doing anything, just like it had appeared without me doing anything.
I have no clue why the problem disappeared. It was not a Firefox update that fixed it, it must have been an update to the kernel or to one of the libraries used by Firefox directly or indirectly. I am using Mate with the proprietary Nvidia driver.
]]>This happened to me maybe 10 times over a few days. Very annoying. I had to 'kill' FF.
Yesterday I did two things: erased the FF cache (except for cookies and site data) and 'vacuumed' the FF sqlite database. Since I did that the problem has not manifested. My guess is that what fixed it was erasing the cache rather than vacuuming.
Anyway, just want to mention this in case someone runs into a similar problem.
P. S. I vacuumed with this command in the FF profile folder:
for i in *.sqlite; do echo "VACUUM;" | sqlite3 $i ; done