RAM overload consistently leads to freezing in 17.1 Core

When using my laptop for extended periods of time, or with multiple applications running at the same time, my RAM continues to grow until it is overloaded (16GB RAM). This constantly freezes Zorin, which at best resolves itself after a few minutes of inactivity when the system seems to have closed some random application. Sometimes a hard reboot is required. Do you have any idea what causes this poor RAM management and how to prevent it? Would be grateful for any help!

Did You take a Look in the System Monitor?

What you are describing here is the Out Of Memory Killer mechanism that Linux uses when it runs out of memory. This is not poor management, it's intended as a last resource to prevent the system from crashing entirely.

This sounds like a memory leak: when a program is consuming memory from the system but is not giving it back, or releasing it, when it's done with it. That is an issue that needs to be addressed by the developers of that particular software.

But you need to do some detective work to find out what is causing this. I would start as suggested by @Ponce-De-Leon by running the System Monitor and checking it frequently throughout the day. Eventually, something will stand out as consuming more memory than other processes.


As an aside, you can implement something called ZRAM which compresses the used memory to make more efficient use of it. This will effectively increase the available RAM, although at the cost of CPU work. But, it might just do the trick:

1 Like

Yes of course I did. The thing is that there isn't one single app that is causing the problem on its own. Though Firefox consumes by far the most, when comparing it to other apps.

Just to be clear, I am not intending to bash zorin when saying "bad memory management". They are doing a great job and I am impressed what they are offering!
What I perceive as "bad" management is not the fact, that zorin kills some random app, when running out of memory. It is rather the fact, that it does this "too late" and freezing occurs every time before it. I wonder, why it shouldn't be possible to resort to this last means of killing an app, before the whole system starts to freeze. Since other OS seem to accomplish this, that is what lead me to my description of "bad RAM management"

Well, the thing is that this problem seems to be occurring independent of one single app. I have tried different combinations of apps to reproduce such freezing behavior and it occurred every time once the RAM was overloaded. I hope it is clear what I mean?

I will have a look at it, thank you!

Apologies, I didn't mean to sound too pushy, just wanted to point that out.

I think for now I would prefer to use something like ZRAM which is far more forgiving with the system as a whole, instead of making the OOM Killer more aggressive. If you find that this is good enough, then I'd stick with this approach.
There's also ZSWAP which is supposedly more performant, but I haven't tried and if one doesn't do the job is unlikely that the other will i.e., something else is going on.

Although, another way of looking at this issue is that you are running out of memory regardless, which would definitely point to some sort of memory leak somewhere.

I realize it may not be possible for you to do this depending on your use case, but have you tried running less programs at the same time. What I'm getting at with this is trying to identify that something that always seems to be there when things go south.

Now worries, just wasn't sure if my original message had an unintended undertone.

That is exactly, why I am suspecting a problem. I guess it shouldn't be the standard for the system to freeze once the RAM is full?!

I mean zorin advertises to be compatible with old hardware of at least 1½ GB RAM. With my experience that would probably mean an instant freeze, once eg firefox is opened. However it would surprise me, if this would be the intended definition of compatibility with old hardware...

Or to be more clear: Zorin should run without freezing on less hardware resources than mine. Since freezing occurs regularly with my 16 GB of RAM I suspect a problem.

Maybe someone has some further tips to resolve this behavior without resorting to third party extensions like ZRAM?

I would suspect the Gnome-Shell itself if no application is causing it. You can try reinstalling:

sudo apt install --reinstall zorin-os-desktop

to see if that is enough to jostle it.

I myself have used Zorin OS with 4Gb of RAM without issues, other than the limitations of the hardware itself that is. So, something must be going on there.

We can also look for evidence of misbehaving processes in the log files. If something is running erratically there's a chance that is writing a ton of logs. You probably would've notice less disk space, which you would've mentioned already, but it's still worth to check.

In the terminal, you can run:

sudo find /var/log -not -path */journal/* -type f -size +1M

This doesn't look for anything specific, just to see if there's a log file that is particularly large in size. These typically never get larger than a few Mb; anything beyond that might have some clues as to what's going on.

I will keep that as an option :+1:
However at the current stage this probably would be the last solution.
Since I have no indication why my current install should be corrupt, I would love to avoid the effort that comes with a new install.

Exactly

The only output I got is the following:

/var/log/syslog.3.gz
/var/log/syslog.1
/var/log/syslog

Does that point to anything?

That is a standard file where most applications output debug or error information. A few MBs in size is to be expected. But it's worth checking it just in case:

This checks for any signs of the OOM killer process. You should see at least a few results indicating that the process has started, that's normal:

grep -i oom /var/log/syslog

This command will help you see all the logs since last boot. This will be helpful when you start to notice the issue:

journalctl -xeb

Or drop the b for all logs, not just since last boot.

To look specifically for errors you can run:

jouirnalctl -xep 1..3

Reading logs is more like an art since it can be quite overwhelming.

If you are comfortable sharing the /var/log/syslog file you can upload it to something like Pastebin or Debian Pastezone and we can take a look for you.

The command I posted was one terminal command - it is not an OS reinstall.

1 Like