10

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?

5
  • Can you include the output from: cat /proc/cmdline? Also 4.15.1 is old. The newest is 4.15.11: kernel.ubuntu.com/~kernel-ppa/mainline/v4.15.11 Mar 21, 2018 at 10:56
  • @WinEunuuchs2Unix my output from cat /proc/cmdline is BOOT_IMAGE=/boot/vmlinuz-4.15.1-041501-generic root=/dev/mapper/skon--vg-root ro Mar 21, 2018 at 14:22
  • 1
    I'm seeing this issue too, and I'm interested why this didn't happen in Ubuntu < 17.10. Let me reinforce: I've never seen my system freeze due to exhaustion of RAM (for years). - I've noticed that GNOME Shell seems to use significantly more RAM than Unity used to, but that very problem shouldn't be tied to the desktop, should it?
    – Peterino
    Mar 27, 2018 at 9:16
  • 1
    Another case here. @dsstorefile: in my case (and I guess other users too) the system doesn't grind to a halt but often rather just stops completely with no warning.
    – Erik I
    Apr 23, 2018 at 2:12
  • 1
    Same happens here as well. An unresponsive system due to swapping is one thing, but here the system goes from "everything is fine" to "I can't even move my mouse anymore" within a second. I am pretty sure this is not intended behavior. Jul 21, 2018 at 14:59

1 Answer 1

1

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.

2
  • I have the same issue, except I have swap turned off...
    – Michael
    Jul 30, 2019 at 21:12
  • @Michael Swappiness is usually there to prevent this behavior and from my experience, thrashing usually occurs when swappiness is set too low and RAM is nearly full. This can also happen when the swap space is too small. Setting swappiness too low results in a superficially more responsive system at the cost of less protection against freezes and subsequent disk thrashing if RAM becomes full. If swappiness is less than 60, I would increase to 60. If you are running out of swap space, I would increase the size of the swap file. Even better would be to switch from an HDD to an SSD.
    – mchid
    Feb 21, 2022 at 5:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .