Your message dated Wed, 3 Aug 2011 13:28:49 +0200
with message-id <20110803112849.GC3444@elie.Hillsp>
and subject line Re: Out of memory: Kill process 3254 (Xorg) score 93 or
sacrifice child
has caused the Debian Bug report #636454,
regarding Out of memory: Kill process 3254 (Xorg) score 93 or sacrifice child
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
636454: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=636454
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Subject: linux-source-3.0.0: Out of memory: Kill process 3254 (Xorg) score 93
or sacrifice child
Package: linux-source-3.0.0
Severity: important
I just got the following in dmesg:
[43627.304569] Out of memory: Kill process 3254 (Xorg) score 93 or sacrifice
child
[43627.304571] Killed process 3254 (Xorg) total-vm:595596kB, anon-rss:482176kB,
file-rss:368kB
Needless to say, not a nice interuption to my work :/
Looking through the dmesg log I notice it has killed firefox-bin and kdevelop a
few times before, which explains some "unexpected crashes" I thought had
occurred.
The only obvious solutions are to install more RAM (I currently have 4 GB) or
enable swap (not set up since I'm running off an SSD).
But failing this, I don't find the kernel's current behaviour very acceptable.
Killing processes without user permission isn't nice since it may lose work;
doing so and not telling the user why it suddenly died is worse. Even worse is
killing the xserver which is the parent of most other processes!
In the ideal world the kernel would stop things before RAM ran out completely
and nicely request processes to free memory or end or even ask the user what to
do, but that doesn't seem like it's likely to happen soon. Still, I find
killing the x-server unacceptable. Do you have any ideas what might be done?
Cheers,
Diggory
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.0.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--- End Message ---
--- Begin Message ---
Hi,
Diggory Hardy wrote:
> [43627.304569] Out of memory: Kill process 3254 (Xorg) score 93 or sacrifice
> child
> [43627.304571] Killed process 3254 (Xorg) total-vm:595596kB,
> anon-rss:482176kB, file-rss:368kB
>
> Needless to say, not a nice interuption to my work :/
>
> Looking through the dmesg log I notice it has killed firefox-bin and kdevelop
> a
> few times before, which explains some "unexpected crashes" I thought had
> occurred.
>
> The only obvious solutions are to install more RAM (I currently have 4 GB) or
> enable swap (not set up since I'm running off an SSD).
Yes, you need swap. Maybe you could have luck putting a swap
partition on a throwaway USB thumb drive or setting aside some real
memory to hold compressed data as swap (as in the
http://code.google.com/p/compcache/ project).
Otherwise you can try disabling overcommit:
# to try it:
echo 2 >/proc/sys/vm/overcommit_memory
# to make it permanent:
echo vm.overcommit_memory = 2 >/etc/sysctl.d/dont-overcommit.conf
But I warn you, that setting makes for an unpleasant life --- for
example, a process that has allocated 2 GiB of virtual memory would
not be able to fork() in order to launch another program. Expect
aptitude to run out of memory often. Mitigating that properly would
require implementing posix_spawn() in the kernel instead of emulating
it in libc with fork + exec. Documentation/vm/overcommit-accounting
has details.
Closing since it is not obvious how to turn this report into an
improvement to the kernel. If you have specific ideas for improving
the OOM killer's heuristics, we'd still be glad to hear them. See
"Out-of-memory handling" in the list at http://lwn.net/Kernel/Index/
for inspiration.
Thanks,
Jonathan
--- End Message ---
