Date: Tue, 6 Apr 1999 11:06:27 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Arjan de Vet <Arjan.deVet@adv.iae.nl> Cc: hackers@FreeBSD.ORG Subject: Re: Increasing both NBUF and NMBCLUSTERS leads to panics Message-ID: <199904061806.LAA09677@apollo.backplane.com> References: <199904061651.SAA11984@adv.iae.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
:Hi,
:
:I'm testing a new 3.1-stable server with 640MB RAM for running Squid and
:I would like to increase the NBUF parameter in the kernel configuration
:file. The default maximum size of the buffercache seems to be around
:8MB irrespective of the amount of physical memory (see nbuf calculation
:code in i386/i386/machdep.c).
:
:For this Squid server I would like to have at least 32MB buffer cache or
:more because the 2-level directory hierarchy used by Squid contains in
:my setup 4096 directories whose size is <=8KB and I would like to cache
:all metadata to speedup the open() calls which are becoming a bottleneck
:on my current Squid server on BSD/OS 3.0.
:
:If I understand correctly, metadata only gets cached in the buffer cache
:whereas other file data can be cached by the VM system too. Some time
:ago John Dyson also posted some sysctl settings for keeping metadata in
:the buffer cache as much as possible; I was planning on using those too.
No, it's around physmem ( in kilobytes ) / 8. It should scale ok.
Metadata is cached in the VM buffer cache, which uses all available
memory. The VFS buffer cache, which is the 'nbuf' stuff, is really
only a mapping from the VM buffer cache. Your directories are still being
cached even if you do not have a lot of nbuf's, but since nbufs hold
logical to physical block translations and are used to stage I/O, in your
case having more of them may be beneficial.
:Besides increasing the NBUF parameter I also want to increase
:NMBCLUSTERS of course because the machine will handle quite some network
:traffic. But for some reason increasing both NBUF and NMBCLUSTERS only
:leads to panics :-(.
The problem is that insufficient KVM is being reserved. You need
to upgrade to the latest -CURRENT ( i.e. 4.x ). The fixes will probably
go into -STABLE before the next release, but they are not in yet. The
3.1 release is definitely broken for systems with large amounts of real
memory which try to raise the default limits.
-Matt
:
:Any explanations or hints for avoiding these panics are greatly
:appreciated.
:
:Arjan
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199904061806.LAA09677>