>> Trying to overtake high server load (sudden peaks of 15%us/85%sy, LA> >> 40, very slow lstat() at these moments, looks like some kind of lock >> contention) I enabled vfs.lookup_shared=1 on two servers today. One is >> FreeBSD-7.3 kernel csup'ed and built Sep 9 2010 and other is >> FreeBSD-7.3 csup'ed and built Jul 16 2010. > > The important think you missed is *where* is the supposed lock contention. > If you have lots of processes in "ufs" state, there are other things that > can help you, such as increasing vfs.ufs.dirhash_maxmem.
Before I changed vfs.lookup_shared I did increase vfs.ufs.dirhash_maxmem to 16M. It filled in ~5 minutes, but even while it was not full, server was not running better. Usually there is very small number of processes in ufs state (they are even not in top). That processes I've been talking about I suspect were the consequence of enabling vfs.lookup_shared. I also enabled hwpmc to examine system at the moments of high load, but did not have a chance to use it. What am I afraid of now is that server that is running nice till now may crash, that's why I am asking about stability of vfs.lookup_shared in 7.3. At svn.freebsd.org I see a couple of commits in stable/7/sys/fs/ and ufs/ for last 2 months that could change the behaviour, and this may be the reason why one system is running stable, and another was not. But I am not sure about it, so I am asking experienced people here :) -- // cronfy _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
