| 2017-02-21 21:03:21 |
Mike Pontillo |
bug |
|
|
added bug |
| 2017-02-21 21:03:37 |
Mike Pontillo |
description |
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
In summary, I think the following sysctl values should be the new defaults:
vm.overcommit_memory = 2
vm.overcommit_ratio = 50 |
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
In summary, I think the following sysctl values should be the new defaults:
vm.overcommit_memory = 2
vm.overcommit_ratio = 100 |
|
| 2017-02-21 21:04:56 |
Mike Pontillo |
description |
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
In summary, I think the following sysctl values should be the new defaults:
vm.overcommit_memory = 2
vm.overcommit_ratio = 100 |
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 |
|
| 2017-02-21 21:06:23 |
Mike Pontillo |
description |
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 |
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 |
|
| 2017-02-21 21:06:57 |
Mike Pontillo |
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 |
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 |
|
| 2017-02-21 21:31:03 |
Brad Figg |
linux (Ubuntu): status |
New |
Incomplete |
|
| 2017-02-22 00:57:35 |
Mike Pontillo |
linux (Ubuntu): status |
Incomplete |
Confirmed |
|
| 2017-02-22 15:27:36 |
Joseph Salisbury |
linux (Ubuntu): importance |
Undecided |
Medium |
|
| 2017-02-22 15:29:00 |
Joseph Salisbury |
tags |
|
kernel-da-key |
|
| 2017-02-22 15:29:56 |
Joseph Salisbury |
tags |
kernel-da-key |
bot-stop-nagging kernel-da-key |
|
| 2017-02-22 15:46:48 |
Joseph Salisbury |
linux (Ubuntu): status |
Confirmed |
Triaged |
|
| 2017-03-01 15:39:37 |
Seth Forshee |
bug |
|
|
added subscriber Seth Forshee |
| 2018-09-30 10:02:43 |
Eduard Hasenleithner |
bug |
|
|
added subscriber Eduard Hasenleithner |
