:
:>David Greenman wrote:
:>>
:>> > - I would like to cap the size of the buffer cache at 200MB,
:>> > giving us another 70MB or so of KVM which is equivalent to
:>> > another 30,000 or so nmbclusters.
:>>
:>> That also seems like overkill for the vast majority of systems.
:>
:>But probably not for the large-memory systems (and on the machines
:>with small memory the limit will be smaller anyway). Having a
:>machine with a few gigs of memory and being able to use only 200MB
:>for the buffer cache seems to be quite bad for a general-purpose
:>machine.
:
: Uh, I don't think you understand what this limit is about. It's
:essentially the limit on the amount of filesystem directory data that
:can be cached. It does not limit the amount of file data that can
:be cached - that is only limited by the amount of RAM in the machine.
:
:-DG
:
:David Greenman
:Co-founder, The FreeBSD Project - http://www.freebsd.org
:President, TeraSolutions, Inc. - http://www.terasolutions.com
Yes, and the buffer cache determines how much dirty file-backed data
(via write() or mmap()) the system is allowed to accumulate before
it forces it out, which should probably be the greater concern here.
The issue we face in regards to these limitations is simply that
the kernel only has 1 GB of KVA space available no matter how much
physical ram is in the box. We currently scale a number of things
based on physical ram - sendfile() buffer space, buffer cache, swap
meta space, kernel malloc area, PV Entry space, and so forth.
Machine with large amounts of ram wind up eating up so much KVA that
simple tuning elements such as increasing the number of NMBCLUSTERS
or increasing 'maxusers' can cause the machine to run out of KVA space
during the boot process, resulting in a panic.
All I am suggesting here is that we throw in some reasonable limits
temporarily (until we can come up with a permanent solution), limits
which really only effect machines with greater then 1GB of real memory
and which can be overriden by kernel options, in order to avoid common
tuning configurations (e.g. large number of NMBCLUSTERS, high 'maxusers'
specification) from causing unexpected crashes at boot time. This will
give us time to come up with a more permanent solution.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
