Article:
 |
|
When Linux Runs Out of Memory
|
| Subject: |
|
OOM Behaviour |
| Date: |
|
2006-12-04 06:41:45 |
| From: |
|
Teresa3455
|
|
|
First of all, thanks for the article. I found it very useful.
I compiled loop-callo.c on my desktop machine. I ran it, and suddenly my firefox session was killed by OOM.
I don't understand why firefox was killed instead of the newly-created memory-eating process. Firefox was started much before loop-call was.
Is there anyother way to adjust OOM behaviour other than placing "OOM_DISABLE" on /proc/<pid>/oomadj ?
Thanks
Teresa
P.S : Good link -> http://linux-mm.org/OOM_Killer
|
Showing messages 1 through 1 of 1.
-
OOM Behaviour
2006-12-05 22:53:09
mulyadi_santosa
[View]
It's good to hear that you found this article to be useful. Please don't be hesitate to write further comments about it.
About FF (Firefox) got killed instead of
loop-calloc, I have a pretty good guess that FF had bigger VM size thanloop-callocwhen OOM killer was working in your case. Recall that running time is just one of the killer's criteria, so to predict which application get killed, you need to carefully check all those 7 criterias I have mentioned in the article.I have tried to mimic your case, simply by doing
tail -f /dev/zerowhile FF 1.0.4 was running. Instead of killingtailright away, FF was killed together with other application such as KDE panel and KMail.Topreported that FF consumed ~33MB of virtual memory while free+reclaimable RAM was about ~30 MB before loop-calloc was started.My suggestion, instead of looking ways to disable OOM killer, is to use
ulimitwhenever you want to start a memory hogger application. Start a shell (possibly via xterm or Konsole),ulimit -v <some amount of memory>and start the application after that. Assuming the application does proper checking aftermalloc()and strict overcommit is enabled, there is no need for OOM-killer to randomly kills application..which is in your case, ended up with killing innocent FF.regards,
Mulyadi