:       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 
:       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 
:       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, <[EMAIL PROTECTED]>                || 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.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to