Red Hat Bugzilla – Bug 172593
Swap memory not being used
Last modified: 2015-01-04 17:22:56 EST
Description of problem:
I have 2GB of swap, but every time that I check there is no swap being used.
When swapping is required, the oom killer starts to kill processes.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. start a process that will require swapping
oom killer starts
I don't know how to give more information.
[seward@sonylap1 ~]$ /sbin/swapon -s
Filename Type Size Used Priority
/dev/mapper/VolGroup00-LogVol01 partition 2031608 0 -1
please show the output of 'dmesg' after an oom kill.
Created attachment 120793 [details]
dmesg after an oom kill
theres no oom kill in that dmesg.
How long after the oom killer messages start showing up on the console do I have
they should be there instantly.
Created attachment 120821 [details]
When I'm at runlevel 5 the oom killer messages run all night and still don't
return. Executing prelink in runlevel 3 invokes the oom killer but usually
does not result in a responsive system. After several tries, I was able to end
up with a responsible enough system to redirect the dmesg output to a file.
I've attached that file.
2.6.14-1.1637_FC4 has been released as an update for FC4.
Please retest with this update, as a large amount of code has been changed in
this release, which may have fixed your problem.
can you paste the output of "slabtop -sc" after the oom killer has kicked in?
Created attachment 121026 [details]
kernel 1636: dmesg
Here is the dmesg after the oom killer with kernel 1636
Created attachment 121028 [details]
kernel 1636: slabtop -o -sc
Here is the result of slabtop -o -sc after the oom killer with kernel 1636
Oops! I just noticed that you asked about kernel 163_7_. I'm downloading now.
Created attachment 121034 [details]
kernel 1637: dmesg
Created attachment 121035 [details]
kernel 1637: slabtop -o -sc
there's a 1640 being built right now which will appear at
http://people.redhat.com/davej/kernels/Fedora/FC4/ in a while, which contains a
fix for a memory leak in the file leases code. This could explain why all your
memory is being consumed by slab cache. If this solves your problem, then this
is a dupe of bug 172691
Created attachment 121074 [details]
kernel 1640: dmesg
Created attachment 121075 [details]
kernel 1640: dmesg
Created attachment 121076 [details]
kernel 1640: slabtop -o -sc
Kernel 1640 was did not fix the problem.
kernel-2.6.14-1.1644_FC4 did not help things.
Do you want new dmesg and slabtop output?
Created attachment 121724 [details]
kernel 1644: dmesg
Created attachment 121725 [details]
kernel 1644: slabtop -o -sc
I have been able to get the system to use some swap by opening several large
mozilla sessions, Matlab and VMware. This seems to work OK, but prelink still
triggers the oom kller.
what we really need to know is whats happening in the slabcache at the time that
the kill happens. Can you run slabtop in an xterm, and trigger the prelink
cronjob manually, and watch the output. Do you see buffer_head growing to the
top of the list perhaps, and then disappearing after the kill ?
size-64 gets huge right before the kill
I can no longer replicate the bug with kernel version 2.6.14-1.1656_FC4.