Computer freezing when running out of memory

heinrich5991 · 2015-09-27 21:54:53

My computer sometimes freezes for long periods of time. I believe it is due to Linux running out of RAM. When last I waited the freezing out, it took 30min+ for the OOM killer to kick in and do its job, it killed Firefox (which is probably a good choice, since it eats quite some RAM). Probably unrelated to the problem, journald crashed a few times during the low memory condition. The system load quickly increases while I can still issue a few commands in the remaining seconds when I can hopefully still open a console and execute a killall firefox. Last time the system woke up after that it had a 15min load of >20 (for 2 cores). The tool glances also tells me that the IO wait rises to astronomical levels (>80%) when this OOM stuff happens.

Running the following C program does exhibit a smaller variant of the problem, but the computer only freezes for a few seconds until the OOM killer kills the program:

#include <stdlib.h>
int main(int argc, char **argv)
{
	while(1)
	{
		malloc(1);
	}
}

My system has 4GB of RAM and no swap. This problem has existed on basically all devices that I ever ran Arch Linux on. Some sources suggest enabling swap, but this doesn't seem to solve the problem. Today I googled again and found the following, which does not help either: Ask Ubuntu: Computer freezing on almost full RAM, possibly disk cache problem.

Any ideas?

loqs · 2015-09-27 22:32:26

overcommit_accounting
On my system with the default x64 kernel

$ sysctl vm.overcommit_memory 
vm.overcommit_memory = 0

Now if I understand the link correctly setting that to 2 stops overcommit so firefox for instance would gets its allocations failed sooner.
Hope this helps.
--
Edit Spelling

Last edited by loqs (2015-09-27 22:33:27)

heinrich5991 · 2015-09-28 10:39:16

loqs wrote:

overcommit_accounting
On my system with the default x64 kernel
$ sysctl vm.overcommit_memory 
vm.overcommit_memory = 0
Now if I understand the link correctly setting that to 2 stops overcommit so firefox for instance would gets its allocations failed sooner.
Hope this helps.
--
Edit Spelling

I also have `vm.overcommit_memory = 0`. When I set it to 2, the computer did indeed not slow down when the RAM was getting full, but the OOM killer wasn't invoked either – leading to very weird behaviour of programs. The scrollback of my terminal vanished and when I scrolled a page in Firefox the X server crashed. Setting `vm.overcommit_memory = 2` is probably not the solution to the problem, it just seems to randomly kill programs that aren't able to deal with the OOM (in my case, the X server).

(When I first tried it on a running system, nothing worked anymore, probably because there already was a lot of overcommited memory. I could still type a command in the terminal, but it only told me that it could not execute it due to the lack of memory. A few seconds later the graphical interface crashed and I was left with a blank terminal (such as when you press ctrl+alt+f2), but without any possibility of interacting with it.

niceman · 2015-09-28 11:27:08

How exactly does your computer runs out of memory ? do you open many things at once ? after all 4GB Ram is a big number.

as for the freeze I think it's typical for any OS to slow down or freeze when it runs out of memory As it struggles to find memory for new processes, don't you think so ?

Last edited by niceman (2015-09-28 11:28:20)

heinrich5991 · 2015-09-28 11:32:41

niceman wrote:

How exactly does your computer runs out of memory ? do you open many things at once ? after all 4GB Ram is a big number.

Yes, the low-on-memory condition can certainly be blamed on me, there there are many open programs (and a lot of open tabs in Firefox).

niceman wrote:

as for the freeze I think it's typical for any OS to slow down or freeze when it runs out of memory As it struggles to find memory for new processes, don't you think so ?

Well, that's the part where I think differently – a single program overallocating (most of the time that's gonna be Firefox) shouldn't be able to take down the whole operating system. After all that's exactly why we have operating systems, so that programs that are not well-behaved do not take down the machine. My expectation would be that Linux kills the offending process (which it eventually does, but 30min+ late).

EDIT: As said above, disabling overcommit does stop the system from slowing down, it just has practical problems because processes other than the offender start crashing.

Last edited by heinrich5991 (2015-09-28 11:33:47)

satanselbow · 2015-09-28 16:49:08

Are you maxing out your processor while you are maxing out your memory?

heinrich5991 · 2015-10-08 19:57:53

satanselbow wrote:

Are you maxing out your processor while you are maxing out your memory?

No, I'm not. The "io_wait" value reported by the tool `glances` rises to high values though.

HappyClown · 2015-10-09 01:24:32

Try setting up some sort of RAM/CPU monitor so, when it freezes, you know whether or not it's memory.

heinrich5991 · 2015-10-09 08:18:23

HappyClown wrote:

Try setting up some sort of RAM/CPU monitor so, when it freezes, you know whether or not it's memory.

I had a terminal with `watch free -h` open, it told me that the computer was almost out of RAM when it froze.

Steef435 · 2015-10-09 11:19:18

The procedure in the link you posted is not going to do much if you don't have swap space to begin with. Try creating a swap partition or a swap file first as instructed in the wiki.

heinrich5991 · 2015-10-09 12:42:37

The perceived difference between having swap enabled or not was that the OOM killer was even more reluctant to kill processes when the system was kind-of-OOM, because the working memory exceeeded the available RAM.

Steef435 · 2015-10-09 15:17:26

Well, yeah, a hard disk is slower than RAM, but it should keep the system workable enough to manually close an application once the system starts slowing down. It shouldn't completely lock up when you exceed the 4GBs. Unless your hard disk is very slow.

I assume you'd rather want your system to get a little slow instead of processes randomly getting killed.

Or does the system freeze completely when it starts using swap too?

Arch Linux

#1 2015-09-27 21:54:53

Computer freezing when running out of memory

#2 2015-09-27 22:32:26

Re: Computer freezing when running out of memory

#3 2015-09-28 10:39:16

Re: Computer freezing when running out of memory

#4 2015-09-28 11:27:08

Re: Computer freezing when running out of memory

#5 2015-09-28 11:32:41

Re: Computer freezing when running out of memory

#6 2015-09-28 16:49:08

Re: Computer freezing when running out of memory

#7 2015-10-08 19:57:53

Re: Computer freezing when running out of memory

#8 2015-10-09 01:24:32

Re: Computer freezing when running out of memory

#9 2015-10-09 08:18:23

Re: Computer freezing when running out of memory

#10 2015-10-09 11:19:18

Re: Computer freezing when running out of memory

#11 2015-10-09 12:42:37

Re: Computer freezing when running out of memory

#12 2015-10-09 15:17:26

Re: Computer freezing when running out of memory

Board footer