Description of problem:
Systemd-oomd is very aggressive when it comes to memory management. In fedora 33 I've been able to run quite a few apps without a problem but in fedora 34, the apps get killed way too quickly. Here's an example of atom getting killed by systemd-oomd:
Mar 20 22:18:34 x505za systemd-oomd: Memory pressure for /firstname.lastname@example.org is greater than 10 for more than 10 seconds and there was reclaim activity
Mar 20 22:18:34 x505za systemd: app-gnome-atom-11930.scope: systemd-oomd killed 47 process(es) in this unit.
Mar 20 22:18:36 x505za systemd: app-gnome-atom-11930.scope: Deactivated successfully.
Mar 20 22:18:36 x505za systemd: app-gnome-atom-11930.scope: Consumed 7.557s CPU time
This event is triggered when around 70-80% of my memory is filled up despite still having space in swap.
Version-Release number of selected component (if applicable): systemd 248 (v248~rc4-1.fc34)
Steps to Reproduce:
1. Load up a bunch of apps to fill up memory
2. Wait for systemd-oomd to trigger reclaim activity
Apps get killed very quickly
Apps to run normally until memory and swap is almost full
Ryzen 3 2200u
Seems like if the memory gets filled fast enough, systemd will even decide to kill Gnome
Same problem here.
The fedora defaults are too aggressive. They make systemd-oomd very trigger-happy (ManagedOOMMemoryPressureLimit=10% for 10 seconds)
With 4GB and zram, you can barely use anything. With 2GB it is a task-massacre all the time.
The defaults suggested in the manual (60% & 30s) still prevent excessive spinning while working way more predictably.
I've noticed this too while testing Fedora Workstation 34 this week. I'll leave Netbeans or Brave running to go do something else, and I've got maybe about 4 GB of free RAM out of 8 GB total at that point. Then, some time later, I will try to go back to Netbeans or Brave, or whatever it is, only to find that it's been killed. I've never had anything like this happen before.
I will work on updating the pressure defaults now that the test week results have come in. I agree that the defaults are a bit aggressive, but that's what the test week and beta was meant to iron out.
I've submitted https://src.fedoraproject.org/rpms/systemd/pull-request/58# to bump pressure defaults to 50% for 20s. Hopefully these more conservative values will perform better for most people.
FEDORA-2021-8595b30af3 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-8595b30af3
FEDORA-2021-8595b30af3 has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-8595b30af3`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-8595b30af3
See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-8595b30af3 has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.
Created attachment 1769904 [details]
Today oomd again killed my container.
$ cat /usr/lib/systemd/oomd.conf.d/10-oomd-defaults.conf
$ cat /usr/lib/systemd/system/user@.service.d/10-oomd-user-service-defaults.conf
Created attachment 1769916 [details]
Created attachment 1769918 [details]
@Mikhail Was the system responsive and performing well at 54% pressure on the user service cgroup? Also can you try stopping systemd-oomd (sudo systemctl stop systemd-oomd) and recording what the highest tolerable pressure value was from `/sys/fs/cgroup/user.slice/user-$UID.slice/user@$UID.service/memory.pressure` while your container is running? We can't control for all workloads but it's worthwhile to see what pressure is tolerable or not.