Keep in mind, overcommit considers *committed* address space, not used. So a process which creates a large anonymous mapping but doesn't touch any of that memory (so the address space is committed but no actual pages of RAM are assigned to the address space) will count against overcommit even though it consumes no RAM. Therefore overcommit_ratio=100 is actually pretty conservative, as it's common for processes to have some mappings which don't aren't backed by RAM (but could be).
Deciding exactly what overcommit ratio is appropriate generally is likely to be difficult, since every system has a different mix of processes running which may use mmaps in different ways. One big advantage to overcommit_ratio=0 is that it allows the system to protect critical processes from OOM situations by adjusting those processes' oom_scroe_adj values (systemd allows this value to be specified in unit configuration files). With overcommit_ratio=0, once the limit is reached memory allocations and mmaps start to fail for all processes equally, which might result in critical processes terminating. So I think overcommit_ratio=0 is better for a general use system. In situations where some other arrangement would work better the sysadmin can adjust the sysctl values. -- 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
