Date: Thu, 27 Apr 2000 09:34:41 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Brad Knowles <blk@skynet.be> Cc: "John W. DeBoskey" <jwd@unx.sas.com>, freebsd-current@FreeBSD.ORG Subject: Re: Support for large mfs Message-ID: <200004271634.JAA05279@apollo.backplane.com> References: <200004270554.BAA34693@bb01f39.unx.sas.com> <200004270605.XAA00807@apollo.backplane.com> <v04220800b52da49fcdee@[195.238.23.59]>
next in thread | previous in thread | raw e-mail | index | archive | help
: I use a mfs for storing the Diablo history file on our news
:peering server. Yes, I know the front part of the file is mmap()'ed
:and effectively kept completely in memory anyway, but I've seen
:periods of time when we received over 160,000 articles in a single
:hour (an average of about 45 per second), and if you compare this to
:our normal ratio of offered versus accepted articles (something in
:the range of 32,238,303 vs. 612,429; for a 52.64:1 ratio), this would
:imply we probably did something like 2,368.8 history lookups per
:second during that period of time -- and this is just for inbound
:articles.
:
: In my experience, it is a non-trivial exercise to build a drive
:array system that can keep up with the number of disk accesses
:necessary to handle this many history lookups per second. I think
:I've recently done it (and reported my testing results on
:news.software.nntp, along with summarizing the previous test results
:from Joe Greco and Terry Kennedy), but it's still non-trivial and the
:solutions I've seen so far are all still rather expensive. Thus the
:reason why I currently continue to use an mfs for the history
:database.
:
: However, now I'm wondering if it might not be better to use a
:file-backed or maybe a swap-backed VN device instead of an mfs. Do
:you have any thoughts?
:
:--
: These are my opinions -- not to be taken as official Skynet policy
:======================================================================
:Brad Knowles, <blk@skynet.be> || Belgacom Skynet SA/NV
I can't imagine why MFS would perform better... it shouldn't, every
block is stored in system memory *TWICE* (once in the VM cache, and
once in the mfs process's address space). If you have enough system
memory to create a large MFS filesystem and it performs well, then
the system should perform even better if you remove the MFS filesystem
and just use a normal filesystem.
A swap-backed VN device operates just like a normal disk device except
that you get automatic striping if your swap happens to be striped.
It takes advantage of the fact that the system's VM page cache does
a good job of caching the disk blocks so it doesn't have to.
This is how a normal filesystem works as well. If you have enough memory,
the system should be able to cache a normal filesytem's data blocks as
easily as it caches the VN devices and easier (because they aren't
double-cached) then the MFS device.
I would consider trying a normal filesystem with an async or a softupdates
mount. Or a normal filesystem with softupdates enabled. It may also
help to turn off write-behind (sysctl -w vfs.write_behind=0), though if
you are running the latest 4.x stable the write heuristic is now in and
should do a good job on its own.
-Matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200004271634.JAA05279>