Date: Fri, 06 Mar 1998 21:42:06 -0600 From: Chris Csanady <ccsanady@friley585.res.iastate.edu> To: dyson@FreeBSD.ORG Cc: ccsanady@iastate.edu, freebsd-hackers@FreeBSD.ORG Subject: Re: VM/Buffer cache sizing... (e.g. for serving NFS) Message-ID: <199803070342.VAA06836@friley585.res.iastate.edu> In-Reply-To: Your message of "Fri, 06 Mar 1998 22:13:34 EST." <199803070313.WAA00262@dyson.iquest.net>
next in thread | previous in thread | raw e-mail | index | archive | help
>Chris Csanady said: >> >> I had some questions about the workings of the buffer cache in our >> VM system. Currently, it seems that although the size of the >> cache varies dynamically, the maximum is still preset at compile >> time. Is this accurate? >> >There are two kinds of caching in FreeBSD, (write-back) and >(write-through, read) caching. Note that the write-back caching >is limited to a reasonable size (to keep the disk from being >overwhelmed by pending write requests), but the other cache >is all of memory (including .text and mmapped files.) The two >caches are physically the same and totally coherent, but logically >slightly different. FreeBSD will not sandbag your disk subsystem >with pending write requests. This design keeps the 'sync' command >from freezing your system :-). Ok, I did not realize that there were separate caching policies at work here. I was just looking at the stats that top provides.. probably a rather poor idea. Anyways, thanks for clearing up things, it is nice to know this. I should have just kept quiet and had faith. :) Should have known that there was something like this in place.. >> The reason I ask, is that in linux, it seems to grow dynamically >> until it reaches near the limit of your physical memory. I'm >> not sure how exactly it works, but can something similar be done >> it FreeBSD? If the limit were to be set really high though, >> would it starve everything else? >> >FreeBSD does the same thing, but slightly more intelligently to >avoid such starving. The algorithms are not complex, but are >also not intuitive. > >> When serving NFS to a large set of machines, it would allow for >> the entire file set to remain in cache (at least in our case, >> with 512M of ram.) Is this type of thing possible? >> >Of course :-). :) >To verify that it works on FreeBSD, try running iozone for nearly >the size of memory. You'll find the the read performance is very >high up till some epsilon less than the size of available mem. I will try this. We have not yet decided to use FreeBSD in this application, but I am trying my best. Surely if our other OS keeps up the random crashes, this may easier. I won't name names, but, I'm sure you can guess what it is. :P >The performance problem that you might see is that our metadata >I/O is more conservative and not wide-open, unlike Linux. You >can enable async metadata on UFS filesystems in order to get >similar filesystem consistancy issues like Linux. The ONLY way >that I would enable async metadata on a production, multi-user >server is if there is a UPS on the system. Even then, it requires >careful consideration. Yes, I am familiar with this. I am eagerly awaiting the integration of the soft updates code. :) On the note about linux file systems, a friend of mine recently had some problems. He was doing a parallel make in a directory, and the machine crashed. When it came back up, fsck showed hundreds of errors.. and then whenever he tried to rm -rf the dir, the machine would crash again.. Heh.. Silly OS. :) Chris 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?199803070342.VAA06836>