Unless you have the vm.overcommit_memory sysctl set to 2, and your overcommit is set to less than your system memory.
Then, when an application requests more memory than you have available, it will just get an error instead of needing to be killed by OOM when it attempts to use the memory at a later time.
Yes. Memory allocated, but not written to, still counts toward your limit, unlike in overcommit modes 0 or 1.
The default is to hope that not enough applications on the system cash out on their memory and force the system OOM. You get more efficient use of memory, but I don’t like this approach.
And as a bonus, if you use overcommit 2, you get access to vm.admin_reserve_kbytes which allows you to reserve memory only for admin users. Quite nice.
Unless you have the
vm.overcommit_memorysysctl set to 2, and your overcommit is set to less than your system memory.Then, when an application requests more memory than you have available, it will just get an error instead of needing to be killed by OOM when it attempts to use the memory at a later time.
Isn’t there a trade off though?
Yes. Memory allocated, but not written to, still counts toward your limit, unlike in overcommit modes 0 or 1.
The default is to hope that not enough applications on the system cash out on their memory and force the system OOM. You get more efficient use of memory, but I don’t like this approach.
And as a bonus, if you use overcommit 2, you get access to
vm.admin_reserve_kbyteswhich allows you to reserve memory only for admin users. Quite nice.