*BSD News Article 80717


Return to BSD News archive

Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!munnari.OZ.AU!news.ecn.uoknor.edu!news.wildstar.net!news.sdsmt.edu!news.mid.net!mr.net!www.nntp.primenet.com!nntp.primenet.com!news1.best.com!nntp1.best.com!flash.noc.best.net!not-for-mail
From: dillon@best.com (Matthew Dillon)
Newsgroups: comp.unix.bsd.freebsd.misc
Subject: Re: FreeBSD as news-server??
Date: 14 Oct 1996 11:42:20 -0700
Organization: Best Internet Communications, Inc. (info@best.com)
Lines: 162
Distribution: world
Message-ID: <53u1ic$61i@flash.noc.best.net>
References: <537ddl$3cc@amd40.wecs.org> <Dz375G.76v@news2.new-york.net> <53ott7$579@adv.IAEhv.nl> <53pm5c$5ks@twwells.com>
NNTP-Posting-Host: flash.noc.best.net

:In article <53pm5c$5ks@twwells.com>, T. William Wells <bill@twwells.com> wrote:
:>In article <53ott7$579@adv.IAEhv.nl>, Arjan de Vet <devet@adv.IAEhv.nl> wrote:
:>: Shouldn't make too much difference. However an upgrade to INN would...
:>
:>No, it wouldn't. Almost certainly, INN is slower for a single
:>incoming newsfeed than C news. In this day of huge news spool
:>directories, it is absolutely necessary that the process
:>accepting incoming NNTP *not* write the articles to the spool.
:>The latency this introduces into the protocol slows it down way
:>too much. (No, streaming doesn't help -- many providers have
:>found quite the opposite and have stopped using it....)
:>
:>With bare INN, you cannot even get 2 articles/second on typical

    woa woa!  Not true any more!  Just make sure all of your feeds 
    understand INN's streaming mode.  I get about a 5 articles/sec
    transfer rate from my main news machine to my nntp machine
    under medium load conditions (around 200 nnrpd's users).

    It's harder to tell on the newsfeeds machine, since it has a dozen
    incoming feeds, but I would say the aggregate burst transfer is on the
    order of 10 articles/sec.

:>C news is, in effect, a decoupled system and, more importantly,
:>unlike INN, isn't a memory hog. Thus you can expect C news to
:>function more efficiently than INN for a given piece of hardware
:>and a single incoming feed. It still won't be fast enough for a
:>full feed on typical hardware.
:>

    This is true to a degree, but you hit the big problem with CNews
    on the nose below:

:>If you have more than one incoming feed, things get complex. I'll
:>save my fingers explaining why, as I have no reason to believe
:>that this person has more than one feed.

    ... which is why most people run INN now rather then CNews.

    I'm sure all of these points have been repeated, but I have a little
    time so I'll write down my own list.  These comments pertain to
    one or more full feeds:

    * You need lots of ram.  The machine cannot afford to swap *at all*,
      plus you need enough to keep most of the history file and all of the
      history file page table in core, plus you need enough to be able to
      keep your feeds coming in *while* an expire run is going on.  Expire
      has about the same memory utilization as innd, effectively doubling
      your in-core memory requirements.  Finally, you need lots of left
      over memory for filesystem caching.

    * Lots of spindles.  Separate by functionality.

	(a) /usr/local/lib/news or /news or whatever you want to call it
	    should own its own disk.  The logs *can* be put on the same disk.

	    The partition containing the history file MUST have at *least* 1GB
	    free.  The reason is that it must not only support the potentially
	    100-200MB history file, it must also support the expire run's
	    history file rebuild *AND* support active references to unlinked
	    history files by nnrpd and other programs that will prevent the
	    'old' history file's space from being reclaimed.

	(b) /var/spool/news or whatever you call it.. the news spool,
	    should generally own several disks.  I suggest a minimum of 
	    three disks.

	(c) Overview... it is not strictly necessary to put the overview
	    files on a separate physical disk if you (1) have three or more
	    disks for your main spool and (2) buffer the overview records
	    in the newsfeeds file correctly.

    * If you normally have more then a dozen or so active NNTP users, have
      a *second* machine.  That is, use one machine for your newsfeeds machine
      with a minimal spool, and a second machine for your reader machine with
      a huge spool.  nnrpd processes *kill* INN.

      You can afford to saturate your disks on the newsreader machine, which
      means you can throw four times the number of nnrpd processes on it 
      that you could otherwise throw on a combination newsfeeds and newsreader
      machine.  If you batch the articles between the newsfeeds machine and
      the newsreader machine in bursts, you can even afford to swap on the
      newsreader machine.

    * Make sure INN is compiled properly

	(a) use the history file page table in-core option or the history
	    file mmap() option.  I actually suggest the page table in-core
	    option because most UNIX system's buffer caching algorithms
	    seem to work better with lseek()/read() then with mmap()/access,
	    even though the overhead is greater with lseek()/read().

	(b) Buffer writes to the log file.  It's another configuration option.
	    Be generous :-)  This allows you to put the logs on the same
	    physical disk as the history file.

	(c) Use the absolute latest INN release, with the streaming mode
	    extensions.

	(d) If you run nnrpd, for gods sake use the shared-active patched
	    version!

    * Make sure INN is configured properly

	(a) Use the 'B' option in your newsfeeds file with reasonable
	    buffering numbers.   For example:

overview:\
	*:B4096/1024,Tc,WO:/home/news/bin/overchan

	    It is stupid not to do so.  This reduces the number of context
	    switches and synchronous write-to-pipe calls by an order of
	    magnitude, and tends to bunch up and batch the overchan process.
	    If you do this, it is not strictly necessary to put the overview
	    files on their own disk.

	(b) Use the 'B' option for ALL OUTGOING FEEDS.  If you don't, then
	    every time INN parses an incoming article for redistribution, it
	    will do a synchronous write-to-file or write-to-pipe for each
	    outgoing feed on every incoming article, which kills performance.

	    For example:

nntp1/nntp1.best.com\
	:*\
	:B8192/1024,Tf,Wnm\
	:nntp1

	    It is up to you whether you want to run your outgoing feeds as
	    channels or files.  I tend to run mine to files then run a
	    5 minute batch from cron, but this is more due to historical
	    memory leaks in INND.  I also like to do things that way in
	    order to have more control over the backlog.

	(c) Use innfeed or something similar that supports streaming mode
	    for your outgoing feeds.

    A lot of people are so blasted worried about propogating articles 
    instantly, that they use low 'B' option buffering or no buffer at all,
    and use real time channels rather then 5 or 10 minute file batches....
    and get really horrible performance as a result.  

    I also hear people complain about all the fork/exec's... I point out
    to such people that (a) channels have to fork/exec too, and with
    much greater overhead doing so from innd rather then cron, and
    (b) unless you have > 20 feeds, doing 20 fork/exec's from cron once
    every 5 minutes has almost no overhead, and you can even stagger them
    from cron to create less disk contention.  This is verse the real
    time channel feeds which, even when buffered, give you NO ability
    to stagger their operational starts to reduce disk contention.

    If you are not afraid of a pidly 5 or 10 minute propogation delay,
    then use proper buffering and 5/10 minute file batches rather then
    channels.  If you really are in love with channels, then at least use
    relatively large buffering parameters.

						-Matt

-- 
    Matthew Dillon   Engineering, BEST Internet Communications, Inc.
		     <dillon@best.net>
    [always include a portion of the original email in any response!]