Suddenly slow lstat syscalls on CURRENT from Juli

Beat Gätzi beat at
Sat Jan 1 16:42:56 UTC 2011

On 01.01.2011 17:12, Kostik Belousov wrote:
> On Sat, Jan 01, 2011 at 05:00:56PM +0100, Beat G?tzi wrote:
>> On 01.01.2011 16:45, Kostik Belousov wrote:
>>> Check the output of sysctl kern.maxvnodes and vfs.numvnodes. I suspect
>>> they are quite close or equial. If yes, consider increasing maxvnodes.
>>> Another workaround, if you have huge nested directories hierarhy, is
>>> to set vfs.vlru_allow_cache_src to 1.
>> Thanks for the hint. kern.maxvnodes and vfs.numvnodes were equal:
>> # sysctl kern.maxvnodes vfs.numvnodes
>> kern.maxvnodes: 100000
>> vfs.numvnodes: 100765
>> I've increased kern.maxvnodes and the problem was gone until
>> vfs.numvnodes reached the value of kern.maxvnodes again:
>> # sysctl kern.maxvnodes vfs.numvnodes
>> kern.maxvnodes: 150000
>> vfs.numvnodes: 150109
> The processes should be stuck in "vlruwk" state, that can be
> checked with ps or '^T' on the terminal.

Yes, there are various processes in "vlruwk" state,

>> As the directory structure is quite huge on this server I've set
>> vfs.vlru_allow_cache_src to one now.
> Did it helped ?

No, it doesn't looks like setting vfs.vlru_allow_cache_src helped. The
problem was gone when I increased kern.maxvnodes until vfs.numvnodes
reached that level. I've stopped all running deamons but numvnodes
doesn't decrease.

>>> You did not specified how much memory your machine have, but I assume it
>>> is > 1GB. Anyway, increase of maxvnodes on i386 should be done very
>>> cautiously, since it is easy to exhaust KVA.
>> The server has 4GB of RAM. Is it possible to check how much i could
>> increase kern.maxvnodes without exhausting KVA?
> The RAM check is mostly to make sure that you have enough physical RAM
> to cover whole possible KVA (1GB). Too aggressive settings for maxvnodes
> would cause panic.
> Default settings of 100000 is more or less optimal for the i386 arch.
> If you need more, you should switch to amd64.

I see. Unfortunately the used CPUs are still 32bit CPUs so switching to
amd64 is not that easy.


More information about the freebsd-current mailing list