linuxµÍ¶ËÄÚ´æÓùâºó»áµ¼ÖÂoom killerËæ»úkillµô½ø³Ì

µ±ÄÚ´æ³öÏÖ²»¹»ÓõÄʱºò£¬oom-killer»ákillµôһЩ½ø³Ì
Õâ¸öÐÅÏ¢¿ÉÒÔÔÚ/var/log/messgerÀï²éµ½
µ±ÕâÖÖÇé¿ö³öÏÖµÄʱºò£¬¿ÉÒÔ½«ÏµÍ³ÀïһЩnattachΪ0µÄshmÇåÀíµô
¹ØÓڸߵͶËÄÚ´æµÄÎÊÌâ¿ÉÒÔ¿´ÈçÏÂ
Since this problem seems to popup on different lists, this message has
been cross-posted to the general Red Hat discussion list, the RHEL3
(Taroon) list and the RHEL4 (Nahant) list. My apologies for not having
the time to post this summary sooner.
I would still be banging my head against this problem were it not for
the generous assistance of Tom Sightler <ttsig@xxxxxxxxxxxxx> and Brian
Long <brilong@xxxxxxxxx>.
In general, the out of memory killer (oom-killer) begins killing
processes, even on servers with large amounts (6Gb+) of RAM. In many
cases people report plenty of "free" RAM and are perplexed as to why the
oom-killer is whacking processes. Indications that this has happened
appear in /var/log/messages:
Out of Memory: Killed process [PID] [process name].
In my case I was upgrading various VMware servers from RHEL3 / VMware
GSX to RHEL4 / VMware Server. One of the virtual machines on a server
with 16Gb of RAM kept getting whacked by the oom-killer. Needless to
say, this was quite frustrating.
As it turns out, the problem was low memory exhaustion. Quoting Tom:
"The kernel uses low memory to track allocations of all memory thus a
system with 16GB of memory will use significantly more low memory than a
system with 4GB, perhaps as much as 4 times. This extra pressure
happens from the moment you turn the system on before you do anything at
all because the kernel structures have to be sized for the potential of
tracking allocations in four times as much memory."
You can check the status of low & high memory a couple of ways:
# egrep 'High|Low' /proc/meminfo
HighTotal: 5111780 kB
HighFree: 1172 kB
LowTotal: 795688 kB
LowFree: 16788 kB
# free -lm
total used free shared buffers cached
Mem: 5769 5751 17 0 8 5267
Low: 777 760 16 0 0 0
High: