Public bug reported:
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
** Affects: linux (Ubuntu)
Importance: Undecided
Status: New
** Description changed:
It seems that running a couple of LXD containers and VMs on my laptop
(16 GB RAM, 16 GB swap) was is the kernel oom-killer to be frequently
triggered.
First I tried limiting the memory my containers were allowed to use,
such as by using:
- lxc config set <container> limits.memory 1024GB
+ 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".
+ 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
+ http://serverfault.com/a/510857/15268
In summary, I think the following sysctl values should be the new
defaults:
- vm.overcommit_memory = 2
- vm.overcommit_ratio = 50
+ vm.overcommit_memory = 2
+ vm.overcommit_ratio = 100
** Description changed:
It seems that running a couple of LXD containers and VMs on my laptop
(16 GB RAM, 16 GB swap) was is the kernel oom-killer to be frequently
triggered.
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
** Description changed:
- It seems that running a couple of LXD containers and VMs on my laptop
- (16 GB RAM, 16 GB swap) was is the kernel oom-killer to be frequently
+ 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.
- First I tried limiting the memory my containers were allowed to use,
- such as by using:
+ 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
** Description changed:
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".
+ 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
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1666683
Title:
Default VM overcommit sysctls in Ubuntu lead to unnecessary oom-killer
invocation
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1666683/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
