4

When I use too much RAM on my Ubuntu 18.10, the GUI freezes. It stops reacting to keyboard and mouse and there is nothing to do other than hard reset the computer.

I believed that this was because the system has swapped out the Gnome binaries to disk and that, eventually, they would be swapped back. But this never happened in the observed timeframe (20 minutes or so).

I tried to solve the problem by disabling swapping (I prefer to lose unsaved work to losing unsaved work and having to restart the PC) and by instructing the OOM killer to kill whichever process has triggered the OOM situation according to this answer. However, this did not help. I tried to use a lot of memory by opening too many browser tabs and the only thing that happened was that the system became unresponsive again.

How is this possible? What other mechanism than thrashing could be involved? (genuine engineering question, not a rant)

I monitored the system stats during this experiment and it seems that the CPU was not running under 100% load, so it was not the computational constraint. Furthermore it seems that the GUI froze before I had the chance to open enough tabs to trigger the OOM killer.

enter image description here

The best theory that I can come up with is that the GUI libraries are using some sort of memory allocator that allows them to continue functioning even with very little memory, either by using some alternative swapping mechanism or by some CPU intensive heap rearrangements. Otherwise I have no clue.

Is there any better explanation for this behavior? Or a solution even?

EDIT

my swappiness:

vm.swappiness = 60

my memory:

martin@martin-UX305UA:~$ free -h
              total        used        free      shared  buff/cache   available
Mem:           7.7G        5.5G        145M        993M        2.1G        975M
Swap:          2.0G         57M        1.9G

my /etc/fstab

UUID=e0edf45b-903c-403f-b2c7-5e69b8b450da /               ext4    errors=remount-ro 0       1
# /boot/efi was on /dev/sda1 during installation
UUID=0564-1C88  /boot/efi       vfat    umask=0077      0       1
/swapfile                                 none            swap    sw              0       0
Martin Drozdik
  • 3,344
  • 6
  • 32
  • 39

2 Answers2

2

It is worth to try to use some improved version of OOM-killer. Like earlyoom or nohang. There are more alternatives described on their websites.

These userspace apps can react much faster than regular kernel OOM-killer.

nohang maintainer on github is very actively responding to issues in case you will have any.

This linux podcast provides some audio introduction on the topic.

LVitya
  • 121
1

Note: You really need to add more RAM, but we'll try this...

Every system needs a swap partition or /swapfile.

  • remove OOM tweaks

  • change your currently unused 2G /swapfile to at least 4G

  • adjust vm.swappiness

/swapfile

Note: Incorrect use of the dd command can cause data loss. Suggest copy/paste.

sudo swapoff -a           # turn off swap
sudo rm -i /swapfile      # remove old /swapfile

sudo dd if=/dev/zero of=/swapfile bs=1M count=4096

sudo chmod 600 /swapfile  # set proper file protections
sudo mkswap /swapfile     # init /swapfile
sudo swapon /swapfile     # turn on swap
free -h                   # confirm 8G RAM and 4G swap
reboot                    # reboot and verify operation

Assure this line is in /etc/fstab...

/swapfile    none    swap    sw      0   0

vm.swappiness

In the terminal, try...

sudo sysctl vm.swappiness # to see original value (=60)

sudo sysctl vm.swappiness=80 # change RAM vs swap ratio

To make permanent...

Set vm.swappiness=80 (based on 8G RAM and 4G SWAP), this way...

sudo -H gedit /etc/sysctl.conf # edit this file

Search for an existing vm.swappiness= entry...

CTRL+f vm.swappiness

  • If found, edit it to say vm.swappiness=80

  • If not found, add vm.swappiness=80 at the end of the file

Save your edits and quit gedit

sudo sysctl -p

heynnema
  • 73,649