2

There are zillions of questions like this but none has an answer that works for me. Perhaps my system is just misconfigured.

My problem is that after some uptime (a few days), the RAM on my desktop machine (Ubuntu 16.04 LTS) is completely filled and the GUI starts lagging and becomes unresponsive / unusable.

Output of free:

              total        used        free      shared  buff/cache   available
Mem:       16326212     5633804      395072    10026328    10297336      184458
Swap:             0           0           0

What does not help is this:

sync; sudo sh -c 'echo 3 >/proc/sys/vm/drop_caches'

=> virtually no change in above numbers

swapoff -a

=> no change (swap is disabled anyway)

A striking difference to all outputs of free being posted in related questions is that most of my memory is taken up by shared.

However, ipcs -m | awk '{sum+=$5} END{print sum}' yields a number around 213 MB only.

Possibly related: I have several paths mapped to a RAM disk (from /etc/fstab):

tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0
tmpfs /var/tmp tmpfs defaults,noatime,mode=1777 0 0
tmpfs /var/log tmpfs defaults,noatime,mode=0755 0 0 
tmpfs /var/log/apt tmpfs defaults,noatime 0 0

but there doesn't seem to be any problem there:

Filesystem           Size  Used Avail Use% Mounted on
tmpfs                1.6G   22M  1.6G   2% /run
tmpfs                1.6G  132K  1.6G   1% /run/user/1000
tmpfs                5.0M  4.0K  5.0M   1% /run/lock
tmpfs                7.8G     0  7.8G   0% /sys/fs/cgroup
tmpfs                7.8G   12M  7.8G   1% /var/tmp
tmpfs                7.8G  1.7M  7.8G   1% /var/log
tmpfs                7.8G  143M  7.7G   2% /dev/shm
tmpfs                7.8G  8.0K  7.8G   1% /var/log/apt
tmpfs                7.8G  878M  7.0G  12% /tmp
...

except perhaps

udev                 7.8G  7.8G     0 100% /dev

Any other ideas?

1

2 Answers 2

1

This line

udev                 7.8G  7.8G     0 100% /dev

was indeed a hallmark of the problem. This mount should probably never be 100 % filled. Having read High SHMem memory usage! I found that bootchart had filled this completely. After uninstalling bootchart and deleting /dev/.bootchart everything is back to normal, including the shared memory usage:

              total        used        free      shared  buff/cache   available
Mem:       16326212     3258332     7929904     1177272     5137976    10981178
Swap:             0           0           0
0

You need to find out what fills your computer's memory. The first thing that comes to my mind is the browser. Modern browsers use insane amounts of memory.

You can find out what uses what amount of memory with smem. There's smem packaged for Ubuntu 17.x here: https://packages.ubuntu.com/artful/smem. It only depends on python and python-matplotlib, which are available on Ubuntu 16.x. So you should be able to download the smem package and install it with dpkg -i smem_1.4-2_all.deb.

After installing it you can just run smem and will see which process is using how much memory.

Once you find out what fills the memory, then you can just stop that process. F.ex. closing tabs in the browser helps. Also stopping and starting the browser can help freeing some memory.

One more thing - you should enable swap. The swap will extend your available memory.

One other thing - since - apparently - you aren't using swap, then "the GUI starts lagging and becomes unresponsive / unusable" is probably not caused by the memory being filled up, but by either some process accessing the disk too much (a running backup, rebuilding the mlocate database come to my mind) or using the CPU too much. You should be able to diagnose "too much CPU usage" with top and too much I/O usage with iotop (apt-get install iotop).

5
  • It's firefox and chromium filling up the memory. I know people recommend swap -- still 16 GB (- RAM disk) ought to be enough, so I'd rather go without. In fact, the unresponsiveness starts with the kswapd0 process kicking in. Nov 26, 2017 at 15:20
  • So does this answer your question? Nov 26, 2017 at 18:14
  • I'm afraid it does not. Nov 27, 2017 at 16:26
  • Then I'm afraid I can't find out what your real question is. You are asking "Memory full, mostly taken by “shared”, GUI unresponsive". Now you know what's using the memory: the browser. You also know which the machine is getting unresponsive: because of swapping. You see that most of the memory is used by "shared": the browser processes are using a lot of shared memory. So, what's missing? You should be able to find out who is using how much shared memory with smem, ps auxw and cohorts AFAIK. Nov 28, 2017 at 7:53
  • I am currently trying to reduce the size of /dev/shm to see if that avoids the issue of running out of memory. Nov 28, 2017 at 8:32

You must log in to answer this question.

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