Bug 13205 - System becomes unresponsive on heavy RAM/swap use
Summary: System becomes unresponsive on heavy RAM/swap use
Status: RESOLVED OBSOLETE
Alias: None
Product: Memory Management
Classification: Unclassified
Component: Page Allocator (show other bugs)
Hardware: x86-64 Linux
: P1 normal
Assignee: Andrew Morton
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-04-29 05:25 UTC by rocko
Modified: 2015-02-19 19:09 UTC (History)
6 users (show)

See Also:
Kernel Version: 3.2.6
Subsystem:
Regression: No
Bisected commit-id:


Attachments
C++ Utility to allocate chunks of memory of user defined size in MiB (3.71 KB, application/octet-stream)
2009-05-16 05:44 UTC, Ulrich
Details

Description rocko 2009-04-29 05:25:12 UTC
I'm running Ubuntu 9.04 with the 2.6.30.rc3 kernel on a laptop with 4GB of RAM and 4GB of swap. When I run three VirtualBox (version 2.2 PUEL) VMs each with around 1.4GB of RAM, as soon as the kernel starts to use swap (as shown by atop -d) the system effectively becomes unusable - the HDD thrashes away, X windows stop responding, the keyboard stops responding, you cannot ssh in from another PC. I can move the mouse, but only very slowly and in staccato fashion. The gnome-terminal running sudo atop -d seems to stop refreshing after it indicates that about 300MB of swap is in use. Clicking on windows to try and close them has no effect. The only solution is to hard reset the machine. I have waited up to 15 minutes to see if things would improve.

I would expect that at the very least I should be able to access gnome-terminal or a VT console and manually kill processes to make the system usable again; at best it would be great if memory management could detect such a condition and take some action like freezing memory-hungry processes.

This occurred also in earlier kernels, eg 2.6.27 (Ubuntu 8.10) and 2.6.28 (the stock kernel in Ubuntu 9.04).

I'm guessing this is something to do with kswapd but I don't know which part of memory management this might fall under, so I'm just going to guess at page allocator.
Comment 1 Ulrich 2009-05-16 05:44:57 UTC
Created attachment 21370 [details]
C++ Utility to allocate chunks of memory of user defined size in MiB
Comment 2 Ulrich 2009-05-16 05:46:47 UTC
I have very similar problems and would like to add the following references:

http://bbs.archlinux.org/viewtopic.php?pid=390313#p390313

https://bugs.launchpad.net/ubuntu/+bug/283420
https://bugs.launchpad.net/ubuntu/+source/linux-meta/+bug/159356


Could you also consider the following (quoting my own LKML posting from 2009-05-11 1:58):

****

To reproduce this, I've attached (above) a small C++ utility
(compiles with g++ memory_overcommit.cc -o memory_overcommit.bin) which
allocates chunks of memory of user defined size. (Also here: http://datenparkplatz.de/DiesUndDas/memory_overcommit.cc)

On the Ubuntu system, the system freeze can be observed with swap
enabled on a cryptographic swap partition (dm-crypt; /etc/crypttab).
With openSUSE the lock-up also occurs with deactivated swap.
(swapoff -a).

Tested from a KDE terminal window as regular urser, the
steps to reproduce are:

* use cryptographic swap partition or disable swap
  (maybe also reproducible with normal swap; but apparently not on Suse)

* compile and invoke the attached code:
  ./memory_overcommit.bin

* enter a number (in MiB) of memory that is slightly smaller than the
available memory and press "enter" key once.

* enter a smaller number (minimum 1 MiB) and confirm again, do the same
again,..., successively approaching the limit of available memory with
smaller chunks.

* finally, when most of the memory/buffers/cache are used-up, the system
becomes unresponsive and constant, heavy harddisk-access commences.

Sometimes, more than one attempt is needed to yield the behaviour.
Comment 3 rocko 2009-08-17 00:36:02 UTC
I installed an i386 kernel (2.6.30.4 configured to use PAE) to compare to the 64 bit kernel (2.6.30.4) and ran some comparison swap tests between them:

* I started up two VBox VMs taking up approx 2 GB between them and waited until disk activity settled.

* I told file-roller to tar /usr/src/linux-2.6.30.4. This process takes up an ever-increasing amount of RAM (I assume it's because of some symbolic links that link back into the same folder - I've got /usr/src/linux linked to /usr/src/linux-2.6.30.4).

X under the the 32 bit kernel is still reasonably responsive, even when it is swapping and file-roller is taking up around 1.5GB of RAM and 2.5GB of virtual memory. (file-roller vanishes without warning when it gets to about 3GB of virtual memory.)

X under the 64 bit kernel just about freezes completely _as soon as_ it starts swapping. Since file-roller doesn't die, I have to hard-reset the system unless I have the patience to ssh in and kill it manually (which takes five to ten minutes, the system is so unresponsive).
Comment 4 rocko 2009-08-17 00:36:42 UTC
Also, http://bugzilla.kernel.org/show_bug.cgi?id=13849 looks like it might be related to this bug.
Comment 5 rocko 2010-04-07 04:45:29 UTC
I think I ran into this problem again with 2.3.34-rc3. The drive went crazy and the system was for all intents and purposes unusable. It hasn't happened in 2.6.33, however.
Comment 6 rocko 2010-04-07 04:46:30 UTC
And of course I meant to say 2.6.34-rc3, not 2.3.34-rc3.
Comment 7 Peter Hoeg 2010-11-08 06:41:43 UTC
I am seeing this on .35 and .36 as well on two different machines.
Comment 8 nfxjfg 2012-02-25 07:26:28 UTC
I have his problem in 3.2.6, and I think it didn't exist on 2.6.32.

As soon as an application requests more RAM than what is physically free, the system gets mostly unresponsive. X freezes, you can't even move the mouse cursor, and it takes a long time until it unfreezes. This happens even if the amount of memory requested by the application is relatively small (like 200 MB).

I wonder how it is possible that X freezes in this case, even if it's not doing any disk I/O and likely isn't doing any large memory allocations.

I'm not swapping to an lvm/luks partition.
Comment 9 rocko 2012-05-30 23:38:30 UTC
I've seen it happen in 3.4 as well, but the kernel behaves considerably better than in the 2.6.32 to 2.6.36? kernels where I originally experienced the bug. The system does freeze but it is only for 30 seconds or so, whereas in 2.6.32 I gave up waiting after 15 minutes.
Comment 10 Alan 2015-02-19 15:29:09 UTC
This bug relates to a very old kernel. Closing as obsolete.
Comment 11 Mikhail 2015-02-19 18:57:24 UTC
Alan,new kernels having problem with swap too
Described here: https://bugzilla.kernel.org/show_bug.cgi?id=60533
Comment 12 Alan 2015-02-19 19:09:52 UTC
Thats fine they have their own bug

Note You need to log in before you can comment on or make changes to this bug.