I've got an eeePC 900a: it has a 8GB flash as disk and only 1GB of RAM. The Linux distribution installed on it is ArchLinux.

When the system runs out of memory it becomes extremely unresponsive: it takes several seconds/minutes to do things like switching to TTY1 or even moving the mouse pointer. Sometimes it looks like the system just freezes: three ours ago I let it alone and nothing at all is changed so far.

I'd rather avoid creating a swap partition/file on this eeePC since the disk is already that small, and also because the many writes on the swap space would shorten a lot the flash card life. Moreover I think that a swap file/partition would just move the problem, rather than definitely fixing it.

Isn't the kernel supposed to kill some random applications when it runs out of memory? Why does it fail (or takes ages) at doing that?

A few months/years ago I already tried to look further into this, but couldn't find anything that would actually work...

  • 1
    What DE/WM are you using in your setup, what services/daemons are you running? Using a full fletched desktop environment and browsing with Chromium or Firefox for instance eats your RAM for brunch. 1GB of RAM should be sufficient to run Arch Linux itself, but what really matters is what you put on top of it.
    – user13742
    Commented Jan 3, 2012 at 0:02
  • 1
    I'm using LXDE. Chromium is the program that usually takes most of the RAM. Anyway this is not the point. It's not me who must care about how much memory my system is using, it's my system who shouldn't die because of that. If my system is running short on memory, it's free to kill any application it wishes, I just want it not to freeze!
    – peoro
    Commented Jan 3, 2012 at 0:14
  • 9
    I mean, I'm seriously thinking about running a script like this (in pseudocode): while(true){ if( $FREE_MEMORY<10MB ){ kill -9 $RANDOM_PID; } }. This would definitely fix my problem. But wait, isn't the kernel supposed to do that (and in a far better way than my script)? Why isn't it doing its job?
    – peoro
    Commented Jan 3, 2012 at 0:19
  • 2
    @Marcin, that would only move the problem, won't fix it. Even if I had 4GB of memory (thanks to some swap), my system could run out of memory (thus hanging). What I want to avoid is my system freezing when it's out of RAM. If my kernel would just suddenly kill chromium as soon as my RAM is over I'd be happy even with the 1GB I've got now.
    – peoro
    Commented Jan 3, 2012 at 0:28
  • 4
    @Lee The "magic sysrq" is a key combo that goes directly to the kernel. This will often work even if the keyboard and mouse are unresponsive. See en.wikipedia.org/wiki/Magic_SysRq_key
    – Raman
    Commented Aug 28, 2017 at 23:51

4 Answers 4


It is possible to call OOM-killer (out of memory killer) directly by keyboard combination:


SysRq key is usually combined within PrtSc key on keyboards.

OOM-killer kills some process(-es) and system becomes responsive again.

Thx Raman for advice on this feature in comments above.

PS: This helped me a lot. I agree with opinion that this is the most useful advise about that problem if it caused by Chrome or whatever memory greedy software. But you need to keep in mind that OOM-killer could kill some really important process, use it carefully.

  • 4
    I have the key PrtScn|SysRq. But pressing SysRq - F only gets a screenshot
    – wsdzbm
    Commented Aug 28, 2017 at 16:49
  • 4
    Since you basically took my comment above and made it an answer, a small attribution would have been nice. I upvoted you anyway. :-)
    – Raman
    Commented Aug 28, 2017 at 23:53
  • 5
    @Lee You have to enable it. Some distros don't have magic sysrq enabled by default. This should help: google.ca/search?q=sysrq+enable
    – Raman
    Commented Aug 28, 2017 at 23:55
  • 3
    @Raman I bet 99% who find this can't "enable it" by default because their machine is already frozen... why it's not enabled by default?
    – themihai
    Commented Jan 16, 2018 at 21:09
  • 3
    @themihai because many people consider it a security risk -- it gives you direct access to the kernel via physical access to an input device, regardless of application state e.g. lock screens and such.
    – Raman
    Commented Jan 17, 2018 at 4:27

Recently I found a solution to my problem.

Since the Linux OOM killer isn't able to do its job properly, I started using a userspace OOM Killer: earlyoom. It's written in C, fairly configurable and it's working like a charm for me.

I've also heard about some alternatives, like Facebook's OOMD, developed to run on their servers, but I haven't tried this one


The natural state of things is that application data is in RAM, and files are on disk.
The ideal state of things, performance wise, is that data in frequent use is in RAM, and data that isn't needed at the moment is on disk.
On a normal system, the kernel does two things to attempt to reach this ideal:

  • Application data that has not been used for a while can be moved to disk: this is swap.
  • Data from files that has been used recently is kept in RAM: this is the disk cache (for data read from disk) and disk buffers (for data that is about to be written to disk).

On a typical system, a significant part of the RAM is devoted to the cache and buffers (50% is a typical figure). Since RAM is a finite resource, this may require displacing some application data to swap (swap is only necessary if there is a better way to use the RAM).

On a system with no swap, there's a point when the application data is using almost all the RAM, and so there is barely any room left for cache. Then the system is likely to be slow. The kernel will not start killing applications until it really has to. As long as applications only fill 99% of the available memory, the system keeps going, but very slowly because files data has to be loaded and reloaded from disk all the time. With the same applications running, the system would be faster with swap at that point.

For more on this issue, see this lkml discussion and this blog post.

I don't know of a direct way to tell the kernel to reserve a minimum amount of RAM for the disk cache. You could set up a small part of your RAM as swap space, perhaps even compressed. There are success reports on that front, though I make no guarantees in your particular case.

  • 1
    Thanks for the explanation and links, they helped to clear some doubts about swap. following @Marcin answer to my question, I set up 256MB of compressed virtual swap (compcache) in my RAM. This however doesn't fully answer my question: I understand that my system will be slow when the whole RAM is used only by application and nothing is cached; Still I can't understand why this system hangs for minutes/hours (maybe forever?) when I'm totally out of RAM. I think that my kernel is not doing its job in killing applications when out of memory, if 3 hours aren't enough to switch to TTY1.
    – peoro
    Commented Jan 3, 2012 at 2:44
  • I have swap disabled with 32GB of physical memory and when bad software runs away with memory allocation (hello ld, you piece of garbage), it still hangs for almost a minute, waking up just enough to let me move the incredibly laggy mouse for a second or two every several seconds. Linux's OOM handling is complete crap. If I'm lucky, the OOM killer kills the right process without screwing up the desktop environment completely. And I'm a huge fan of Linux. It's much much worse with paging enabled. Linux paging is a joke.
    – doug65536
    Commented Sep 28, 2017 at 6:22

This is a known bug since 2007 - see System freeze on high memory usage.

In this situation, Windows displays a dialog warning the user to close one or more applications.

  • 3
    Seems to be "Unassigned" in Ubuntu. Perhaps the DE should warn the user or even freeze the memory-intensive app?
    – nkkollaw
    Commented May 7, 2018 at 22:28
  • 1
    @nbrogi - anything but silently freeze. But good luck convincing Ubuntu devs to do that. Commented May 17, 2018 at 12:53

You must log in to answer this question.

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