When should I alter overcommit_memory and what should I take into consideration when doing so?

Question

I'm having a PC freeze issue that I can't seem to figure out. I have three identical PCs. They are each custom builds with i7 and 64GB of RAM. The OS drives are 512GB nvme drives. They each run CentOS v7.8.2003 with kernel v3.10. I'm running some custom software that stores huge chunks of data, processes it, and then re-stores it.

It may be relevant to show the custom configurations done to the OS.

Custom fstab:

UUID=xxxxxx     /               ext4    noatime,nodiratime,discard          1 1
UUID=xxxxxx     swap            swap    defaults                            0 0
tmpfs           /dev/shm        tmpfs   defaults,noatime,mode=1777          0 0
tmpfs           /tmp            tmpfs   defaults,noatime,mode=1777          0 0
devpts          /dev/pts        devpts  gid=5,mode=620                      0 0
sysfs           /sys            sysfs   defaults                            0 0
proc            /proc           proc    defaults                            0 0

LABEL=drive1    /data/drive1    auto    noatime,nodiratime,discard,nofail   0 0
LABEL=drive2    /data/drive2    auto    noatime,nodiratime,discard,nofail   0 0
LABEL=drive3    /data/drive3    auto    noatime,nodiratime,discard,nofail   0 0
LABEL=drive4    /data/drive4    auto    noatime,nodiratime,discard,nofail   0 0
LABEL=drive5    /data/drive5    auto    noatime,nodiratime,discard,nofail   0 0
LABEL=drive6    /data/drive6    auto    noatime,nodiratime,discard,nofail   0 0

Custom sysctl.conf:

vm.swappiness=1
vm.vfs_cache_pressure=50

I don't want to go into too much detail on the software but what is relevant is that it receives data at an extremely fast rate. The data is stored to five SATA SSDs connected directly to the motherboard. (writing to 5 in parallel was the only way for the write speeds to keep up with the inflow of data) The data is stored in large chunks (files) that are later processed and then stored to a sixth SATA SSD. I don't know the details of how some of the software works but I do know that some of the processes use large chunks of shared memory.

The Problem: Sometimes the PC will freeze when a new chunk of data comes in. This freeze is unrecoverable and requires a hard reboot. When it occurs is random but it is always at the start of a new data collect. Changing the software parameters and enabling/disabling certain processes can affect the frequency of when the freeze occurs. This doesn't allow me to narrow it down though as it doesn't seem to be tied to a particular process. Its just that some configurations make it more likely to occur. I did find a particular configuration that allows me to consistently recreate the issue so at least that helps for testing.

I have worked with the devs that wrote the software but we are unable to find any issues that could cause a PC to freeze. I have also tested the software for memory leaks but cannot find any.

To my mind all of this points to a memory issue. However, I can't actually find a memory issue. I have used top and free on the command line and System Monitor in Gnome but there are no indications of any memory issues. The CPU load isn't too high and the PC isn't even using half of the 64GB of RAM. If this is a memory issue then I'm either missing something or it is happening so fast that monitoring and logging can't catch it.

Now to the heart of the matter: In an act of desperation, one of my partners did this:

vm.overcommit_memory=2
vm.overcommit_ratio=80

This "seemed" to fix the issue. I can no longer recreate the freeze. If I monitor the memory while going through the steps to recreate the issue, I don't see anything unusual. None of the processes crashed and the software just did what it was designed to do. This makes me feel like the cause of the freeze isn't the software but the way the OS is configured relative to the atypical way the PC is being used.

I have read the documentation but it is unhelpful with regards to how changing overcommit_memory might affect other parts of the system or with providing any examples of when you would want to change it. I've looked for more information on the forums but I mostly find "don't touch it unless you know what you're doing". I also worry about OOM killing important processes if too much memory is requested.

Can someone please tell me when you would want to change the overcommit_memory settings. Does my situation count as one where you would need to change them? If so, what should I look out for in regards to how it could affect other aspects of the system?

Answer 1

First of all, I would check the logs if there's any reference for OOM. You might not see the memory consumption increase until it's too late, if a certain program suddenly tries to consume large amount of memory at once, and then it might be too late.

Secondly, when a system freezes, the best way to analyze the reason is to enable kernel crash dump beforehand, and then to use SysRq magic key (in this case, use the ALT-SysRq-c combo on the keyboard) to generate a core dump of the kernel that could later be analyzed.

Regarding overcommit_memory, you could read about it in man 5 proc:

/proc/sys/vm/overcommit_memory

This file contains the kernel virtual memory accounting mode. Values are:

   0: heuristic overcommit (this is the default)
   1: always overcommit, never check
   2: always check, never overcommit

In mode 0, 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".

In mode 2 (available since Linux 2.6), the total virtual address space that can be allocated (CommitLimit in /proc/mem‐info) is calculated as

CommitLimit = (total_RAM - total_huge_TLB) *
              overcommit_ratio / 100 + total_swap

Many programs try to allocate as much memory as the kernel lets them (which might be, when overcommit is the default 0, very big) and then use it without checking if this memory is actually physically available, which - as the documentation says - lead to the risk of OOM-killer getting triggered. When overcommit is 2, the kernel limits the amount of memory an application can allocate (map) according to the total size of the RAM, the swap, and the overcommit_ratio value, which actually reduces the chances of OOM getting triggered.

Many applications that manage their memory correctly will not die when the kernel fails their mmap(2) request, and just use as much memory as the kernel allowed them to allocate.

I strongly suggest you read section 9.6 - "Overcommit and OOM" in this article for a practical example of how changing overcommit to 2 affects the behavior of his test code and prevents them to of getting OOM-killed.