Ubuntu – Ubuntu freeze when low memory

freezeramswap

My ubuntu server worked for one month without any problem. But last week I had started to use programs that require more memory. And when free memory is around 100MB, system completelly freeze. I cant type anything, move cursor, connect from putty.. simply nothing.. but strange is, that hard drive is still working(is blinking).. I can fully reproduce this problem and it occurs almost every time when free memory is around 100MB. But I have swap file, and in this swap file is enough free space.. Here is my memory status 1 second before it freezed.

    Every 1.0s free -mh                                               Mon Mar 19 17:05:33 2018                                     

               total         used          free         shared      buff/cache     available
Mem:             11G         10G           115M          1.2G             1.5G         115M
Swap:           7.9G        2.4G           5.5G

Here is my linux kernel

Linux xxx 4.15.1-041501-generic #201802031831 SMP Sat Feb 3 18:32:13 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Here is my ubuntu version

No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 17.10
Release:        17.10
Codename:       artful

Here is my swappines, overcommit_memory and overcommit_ratio configuration

vm.swappiness = 60
vm.overcommit_memory = 0
vm.overcommit_ratio = 50

Here is my hardware configuration

Motherboard: PRIME B350-PLUS
CPU            : AMD Ryzen 7 1700 Eight-Core Processor
RAM           : 4GB + 8GB DDR4
Hard drive  : Samsung 960 evo 250GB

Of course, I can upgrade my memory to 16GB, but still i want to have my system stable. Does anyone have some idea what could be wrong?

Best Answer

I believe this is the same question as this one, even though you have swap enabled: https://unix.stackexchange.com/q/373312/306023

Basically the kernel (or kswapd0) is evicting every active process's code (executable) pages in order to free more RAM, thus on every context switch when a process resumes execution, it needs to be re-read from disk into memory and only then can it resume execution.

This needs to happen so many times per second, coupled with the fact that disk are way slower than RAM, that the OS is seen as effectively freezing up. It's as if RAM gets temporarily replaced by the disk, and all of this is because the kernel makes the mistake ofis evicting the running processes's file-backed executable pages too, instead of just the inactive ones.

If you want to try and see what happens if the kernel doesn't evict those, you can recompile the kernel with this patch, seen in this question. What should happen is that the OS should freeze for at most 1 second now instead of minutes(or permanently) and there should be little to no disk thrashing.

Related Question