Re: oom-killer 2.6.8.1

[William Lee Irwin III <wli@holomorphy.com>]

On Tue, Aug 24, 2004 at 11:30:15AM +0200, Anders Saaby wrote:
> OK - I now have some additional info regarding the slapinfo/oom-killer
> issue.
> As I wrote earlier this server is a storage server providing NFS storage to a 
> number of webservers - ondisk filesystem is xfs, kernel = 2.6.8.1. At 03:00 
> some logrotate scripts runs throug a lot of files. It appears that this is 
> what is using the slabs (see this graph, K = M, so max used slab is approx. 
> 700M) 
> http://saaby.com/slabused.gif (values are from /proc/meminfo)
> These are the values (from slabinfo, active_objs), which changed remarkably 
> from 03:00 to 06:00:
> 03:00:        06:00:
> xfs_chashlist  91297    xfs_chashlist     151994
> xfs_inode     243791    xfs_inode         586780
> linvfs_icache 243791    linvfs_icache     586807
> dentry_cache  196033    dentry_cache      430609

xfs has some known bad slab behavior. I think punting this in the
direction of xfs mailing lists may be useful.


On Tue, Aug 24, 2004 at 11:30:15AM +0200, Anders Saaby wrote:
> The server crashed every night at approx. 03:00 to 04:00 - until last night 
> where we changed:
> vm.min_free_kbytes from default (approx. 900K) to vm.min_free_kbytes=32768 
> (32M)
> This seems to solve the problem - Does this make any sense to you? - Or just 
> pure luck?

I guess it makes some sense since it refuses to let slab cut into the
very last bits of RAM. If you're getting temporarily heavily fragmented
with active references it may mean the difference between the box
livelocking/deadlocking and making forward progress.


-- wli