Home Store Blog

VirtualBox High RAM use, no swap use


#1

Just making sure everything is ok here, as I notice as time goes on (couple of hours) my RAM use creeps higher and higher. I am not noticing a speed difference really, it’s not slowing down on me (except when Chrome decides it’s time to hijack the entire CPU on a Facebook ad-script with a point to prove), until it hits around %75 used then I just have to reboot.

One thing I have a concern about is the fact my swap NEVER gets used.
$ free
total used free shared buff/cache available
Mem: 16366816 12017112 270412 300052 4079292 3713556
Swap: 2097148 0 2097148

I’m using the latest LTS with default install, the only partition trick I did on install was mount an external drive as /home. Does this seem right to anyone else? It feels like RAM isn’t being released properly.


#2

Memory is managed by the kernel. The fact that the swap is not in use means that the kernel is not memory stressed. So in reality it is releasing memory as it needs to.

Doesn’t really look to be anything to worry about.


#3

Hopefully Budgie does not share the Gnome memory leak. Does it ?

RAM is the fastest thing your computer uses. So far it should not be a problem to use much of it.

Now you say you have to reboot → because of ram usage, or cpu usage ?

It’s possible to set the moment when swap is triggered, it’s the swappiness by default it’s 60 meaning swap gets used as soon as 40% of RAM occupation.

 cat /proc/sys/vm/swappiness

…to check that value and…

swapon -s

to check if you have an active swap on your system.

And just in case

free -m

is easier to read :slight_smile:


#4

$ swapon -s
Filename Type Size Used Priority
/swapfile file 2097148 0 -2

$ free -m
total used free shared buff/cache available
Mem: 15983 6576 5342 258 4063 8819
Swap: 2047 0 2047

As for when it’s time to reboot, everything just slows down to a crawl, but CPU use is rarely over %50. If left unchecked, it takes about 5 minutes until the entire desktop hangs, the only thing that will move is the cursor, but everything else including keyboard becomes unresponsive. This is the same problem I was having in Mint with Cinnamon. RAM use at about %70, CPU are %50-60, massive slowdown, then eventual hang.

$ cat /proc/sys/vm/swappiness
60

So you said with the value of 60, it should start populating at %40 usage, but again I’m well over that and swap is at 0. I don’t see what I’m missing.

Update: as of right now, it’s shot up to %80 use, no swap being used. Looking in system resource monitor, the numbers are WAY off, my running processes don’t add to what $ free is stating is being used.

$ free -m
total used free shared buff/cache available
Mem: 15983 12019 495 419 3468 3215
Swap: 2047 0 2047


#5

its very curious that you mentioned that this is the same problem with linux cinnamon.

Its a very different desktop environment with very little common between budgie and cinnamon except perhaps Gtk.

So maybe there is something more fundamental here that isn’t related to the operating system - hardware issue?

Have you run a memtest lately to confirm your RAM modules are ok?


#6

I agree with @fossfreedom regarding memtest, it can’t do wrong to check.

system resource monitor may not show all users by default, hence the difference.

In terminal,

top

when things begin to slow down, and try to see « who » uses much cpu and⋅or much ram.

I had thought your swap was not active, but all seems default situation.
Even if the 60 swappiness value may not be so good for desktop.

But before changing that let’s find out the culprit for slowing down your computer.

And try to use this :
format
to improve « readability ».


#7

Well the thing with Cinnamon is, I was running out of RAM and it would hard lock consistently. I upgraded from 8GB to 16GB and it stopped hard locking, but I would have to restart Cinnamon (doing the super+L/restart shortcut) every 15 minutes, because it would go from ~150MB use to over 1GB use and slow to a crawl. As soon as the DE was restarted (from either CLI or GUI) it would go back down and run smooth again for a little while.

Anyways, this morning, this is what I am looking at:

Htop, sorted by MEM use.

And right now, it’s doing “the thing” again, Chrome is sitting there spinning for minutes on end trying to load a page, it takes two minutes to open a .jpg. 30 seconds to take a screenshot, you get the idea I hope. It doesn’t “feel” like bad RAM, it feels like the CPU is being crushed under the weight of massive bloat, like Windows 7 on a single-core. I’m the only user, forgot to add that part.


#8

No, you’re not :wink: let’s say cortimi is the only human user. If you can display all users, we’ll probably see processes run by root. There we may find something.

Any gpu involved, nvidia or amd ?

google-chrome : any extensions / addons ? same without ?

Same with open-source chromium-web-browser instead of google’s spyware ?


#9

This is what happens: CPU gets completely slammed by I have no idea what. RAM fills up, swap doesn’t get used, then CPU gets crippled. This is something endemic to all the Ubuntu distros I have tried. This is an intell i5 4th gen, it REALLY shouldn’t be a driver thing, this is not new hardware, but it is by no means a slouch. I have also have an Nvidia GTX960 with the official drivers running, if that makes any difference.

Before reboot:
HTOP stats

After reboot, EXACT same programs open:
HTOP post reboot

As you can see, sorted by CPU use, my little torrent client is taking up a small bit, I have Spotify, Discord, Tomboy Notes, and Chrome open. This should not be happening, if the kernel is what is handling resources, it is failing at it. RAM is not being released, swap is not being used, and CPU use is out of control. Honestly, I really don’t expect and answer from this because it is obviously going to be something VERY deep in the OS. I have tried all the usual troubleshooting (been a Windows PC tech for over 10 years, most principles apply to Linux) and just don’t know what else to try besides going back to Windows, or rebooting every hour.


#10

please report this to launchpad and paste the bug url here. This is needed to get feedback from the kernel developers. Thanks.

run in a terminal:

ubuntu-bug linux

Summarise your findings when the bug report window opens - then add a copy-paste detail of the stuff above to detail your findings to-date


#11

Here we go:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1789756

Should I have waited to do this until it starts acting up?


#12

The bug report needs to be self-contained - the developers will not open another website such as ours to get more details.

You can edit your description (little yellow circle towards the right of the description) and add more stuff to your bug report.

The bug-triagers will advise futher - I don’t think you needed to wait.


#13

Added summary and added HTOP images. Thanks, guess now it’s time to wait and see.


#14

Did you find something run by user root taking huge amount of ram or cpu ?

Your pictures only show user cortimi, you may sort out by user.

Anyway, your bug file has been confirmed.


#15

Nope


#16

Ok… damn sorry I can’t help.


#17

What is that process running at 65% ? Have you ruled out that bring the culprit? I e what happens if you don’t run it for a period of time?


#18

Oh good spot, I only looked at processes run by root.

Virtualbox, up for 16 hours if I understand correct ?

Cortimi mentioned it in his launchpad bug file.

Don’t know how Virtualbox works but there may be a way to « allocate » specific amount of RAM for it ?

Maybe some help there : https://www.qwant.com/?q=virtualbox%20memory%20leak


#19

That’s the VirtualBox host. That pretty much is the culprit, as it will slowly cause more and more memory and CPU use, but it won’t get released after the program end and all processes for it end. The bad news is, that specific program is the entire reason I have a computer, no choice to NOT run it.

I guess in good news, I am currently using 768k of swap (93% RAM use), so it does function after all!


#20

Ah. Great news … So it’s a bug with virtualbox.

Ok. You could use a kernel compatible solution such as gnome boxes. Should be possible to convert the vdi virtualbox disk to whatever gnome boxes uses.