2 ms·

>I prefer to set vm.overcommit_ratio=0 and then increase vm.vfs_cache_pressure to somewhere between 400 and 10000 depending on the server role, then set vm.min_

>I prefer to set vm.overcommit_ratio=0 and then increase vm.vfs_cache_pressure to somewhere between 400 and 10000 depending on the server role, then set vm.min_free_kbytes, vm.admin_reserve_kbytes and vm.user_reserve_kbytes higher based on the amount of ram in the system using a simple formula." I understand vm.overcommit_ratio=0 but can you elaborate on what the net effect of setting all the rest of of these tuneables to these values is? What does this achieve and how do these work together? >"For systems that are ephemeral, I also set vm.panic_on_oom to 2 so that they self heal. Avoid doing this on databases." I'm guessing this triggers a reboot for you when the OOM evicts a process? Do you do this in conjunction with the above setting? Or is this an alternative?

LinuxBender 8y ago
Each of the memory settings are described in the kernel sysctl [1] documentation. The goal is to create a larger margin for user error or lack of memory budgeting. This often precludes ever needing swap and forces user space applications into the memory that is actually available. [1] - https://www.kernel.org/doc/Documentation/sysctl/vm.txt https://www.kernel.org/doc/Documentation/sysctl/vm.txt All of the settings should be calculated per server role and memory capacity after extensive testing of your application settings and performance. > I'm guessing this triggers a reboot for you when the OOM evicts a process? It triggers a panic if you hit OOM, rather than kicking in OOM killer which often leaves a system broken, sticky and confused. This should only be used for ephemeral systems or systems that do batch work and can handle reboots. This requires people to find the root cause of their over-allocation and fix them.
- bogomipz 8y ago
  >"All of the settings should be calculated per server role and memory capacity after extensive testing of your application settings and performance." So you're basically turning every node/instance into a special snowflake of sysctl settings all in the hopes of preventing an OOM? And you do this every time dev push a new rev of code? This doesn't seem very agile or sustainable at any of kind of scale or release velocity.

LinuxBender 8y ago

Each of the memory settings are described in the kernel sysctl [1] documentation. The goal is to create a larger margin for user error or lack of memory budgeting. This often precludes ever needing swap and forces user space applications into the memory that is actually available. [1] - https://www.kernel.org/doc/Documentation/sysctl/vm.txt https://www.kernel.org/doc/Documentation/sysctl/vm.txt All of the settings should be calculated per server role and memory capacity after extensive testing of your application settings and performance. > I'm guessing this triggers a reboot for you when the OOM evicts a process? It triggers a panic if you hit OOM, rather than kicking in OOM killer which often leaves a system broken, sticky and confused. This should only be used for ephemeral systems or systems that do batch work and can handle reboots. This requires people to find the root cause of their over-allocation and fix them.

bogomipz 8y ago
>"All of the settings should be calculated per server role and memory capacity after extensive testing of your application settings and performance." So you're basically turning every node/instance into a special snowflake of sysctl settings all in the hopes of preventing an OOM? And you do this every time dev push a new rev of code? This doesn't seem very agile or sustainable at any of kind of scale or release velocity.