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,185
  • Without a reasonable swap, I can't even begin to discuss the issue. Please re-enable it, and undo any OOM tweaks, and then we'll talk, ok? What process(es) are driving 100% memory use... a real app, or a test app meant to do that? – heynnema May 10 '19 at 22:18
  • It is hard for me to believe that the swap can make such a difference. I had a swap of 2GB, pre-configured by the Ubuntu installer, which is not much compared to the 8GB of RAM. Please, could you elaborate a little or point me to the relevant resources? For the second question: I am usually using a Java based server and IDE + Chrome which kills me everytime. – Martin Drozdik May 10 '19 at 23:19
  • Chrome is a memory hog. Normally I'd recommend 4G swap for 8G RAM... so why don't you create a 4-8G swap partition or /swapfile. Edit /etc/fstab. Remove the OOM tweaks. Show me sysctl vm.swappiness. – heynnema May 10 '19 at 23:57
  • status please... – heynnema May 12 '19 at 23:03
  • @heynnema Sorry for the delay. I re-enabled the swap, but I am getting sysctl: cannot stat /proc/sys/vm/swapiness: No such file or directory. I will update my question as soon as I have some reasonable configuration. Thank you for your help! – Martin Drozdik May 13 '19 at 12:05
  • It's vm.swappiness. How much swap did you create? partition or /swapfile? Show me free -h and cat /etc/fstab. Try again and report back with your status. – heynnema May 13 '19 at 14:04
  • @heynnema yupps, you're right. I just re-enabled the swap that was originally on the system. It is 2GB. I updated my question to summarize all the information. – Martin Drozdik May 13 '19 at 14:47
  • status please... – heynnema May 13 '19 at 19:31

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
  • 70,711
  • Thank you! I did as you said. I increased the size of the swapfile using this answer https://askubuntu.com/a/1075516/64420 and increased the swapiness and my system no longer freezes. I am quite amazed that actually more swap did the trick, rather than less swap. I am still unable to comprehend how it can be so, but you solved my problem! – Martin Drozdik May 14 '19 at 11:22
  • @MartinDrozdik The change in vm.swappiness made the big difference, as it tells the system to swap more, and the larger /swapfile gives it the room to do so. What vm.swappiness value did you settle on? – heynnema May 14 '19 at 14:04
  • vm.swappiness=80 did the trick for me. – Martin Drozdik May 14 '19 at 14:22
  • More swap does not solve the problem when a process is misbehaving or a system is under-resourced. Performance still degrades, just in a more gradual and less obvious way, until it freezes. – gatopeich May 20 '20 at 10:50
  • @MartinDrozdik Please see the updates in my answer. Specifically the "To make permanent" part. – heynnema May 22 '20 at 14:18
  • @gatopeich Absolutely correct. The solution for not enough RAM is to add more RAM. I say so in my answer. This answer just temporarily forced a larger swap and a change to vm.swappiness. It worked. – heynnema May 22 '20 at 14:19