Changing status to "Confirmed". I don't think there are any relevant
logs for this issue. Here's some anecdotal evidence, though:
# dmesg | grep oom-killer
[1389379.248406] apt-mirror invoked oom-killer: gfp_mask=0x26000c0, order=2,
oom_score_adj=0
[1399428.772409] chrome invoked oom-killer: gfp_mask=0x26000c0, order=2,
oom_score_adj=300
[1421778.653435] java invoked oom-killer: gfp_mask=0x26000c0, order=2,
oom_score_adj=0
[1464982.048253] sh invoked oom-killer: gfp_mask=0x26000c0, order=2,
oom_score_adj=0
[1479431.535969] postgres invoked oom-killer: gfp_mask=0x26000c0, order=2,
oom_score_adj=-900
[1508936.131513] mount invoked oom-killer: gfp_mask=0x24040c0, order=3,
oom_score_adj=0
[1526250.556039] java invoked oom-killer: gfp_mask=0x26000c0, order=2,
oom_score_adj=0
# cat /proc/uptime
1551384.55 11908654.03
So in the ~7 hours since changing these sysctls, the oom-killer hasn't
run, whereas it was running regularly before that.
** Changed in: linux (Ubuntu)
Status: Incomplete => Confirmed
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1666683
Title:
Default VM overcommit sysctls in Ubuntu lead to unnecessary oom-killer
invocation
Status in linux package in Ubuntu:
Confirmed
Bug description:
On my system, running a couple of LXD containers and VMs (16 GB RAM,
16 GB swap) seems to cause the kernel oom-killer to be frequently
triggered.
In order to try to resolve this, first I tried limiting the memory my
containers were allowed to use, such as by using:
lxc config set <container> limits.memory 1024GB
... and restarting the containers for good measure. However, this
didn't resolve the problem.
After looking deeper into what might trigger the oom-killer even
though I seemed to have plenty of memory free, I found out that the
kernel VM overcommit can be tuned with the `vm.overcommit_memory`
sysctl.
The default for value of `vm.overcommit_memory`, 0, uses a heuristic
to determine whether or not requested memory is available. According
to the `man 5 proc`, if the value is set to zero:
"""
calls of mmap(2) with MAP_NORESERVE are not checked, and the
default check is very weak, leading to the risk of getting a
process "OOM-killed".
"""
Which seems to describe exactly my problem. However, upon setting this
value to 2, many of my open programs immediately aborted with out-of-
memory errors. This is because the default value for
`vm.overcommit_ratio` only allows the usage of 50% of the system's
total (memory + swap).
I then found the following answer on Server Fault:
http://serverfault.com/a/510857/15268
The answers to this question seem to make a good case that the
overcommit_ratio should be set to 100.
In summary, I think the following sysctl values should be the new
defaults:
vm.overcommit_memory = 2
vm.overcommit_ratio = 100
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1666683/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
