Newsgroups: news.software.b
Path: utzoo!henry
From: henry@zoo.toronto.edu (Henry Spencer)
Subject: Re: Help!  I'm doing something stupid...
Message-ID: <1991Jun25.154442.20157@zoo.toronto.edu>
Date: Tue, 25 Jun 1991 15:44:42 GMT
References: <4312@anasaz.UUCP>
Organization: U of Toronto Zoology

In article <4312@anasaz.UUCP> rusty@anasaz.UUCP (Rusty Carruth) writes:
>I just brought up Cnews (last patch 7-Dec-1990) ...
>Alas, I must have done something wrong, as relaynews took a full 
>    160 seconds
>to process one 30k batch file.

Okay, the basic problem here is that your C News is out of date. :-)  This
is almost certainly a known bug that was fixed in the March patches.

The heart of the matter is that dbz keeps track of how much news you've
got, so expire can re-size dbz's hash table suitably.  The trouble is the
startup transient when you're starting a news system from scratch.  A bit
of news comes in, then expire runs and says "oh, he's got hardly any news,
give him a nice small hash table"... and then more comes pouring in, and
the hash table is too small.  Dbz copes, but massive table overflow is a
big performance loss.  The table size consistently lags behind the demand
until your news spool starts to achieve a steady state, at which time the
table gets sized properly and things speed up dramatically.  The March
patches introduced a simple fix for this:  dbz refuses to shrink its table
(which is initially fairly sizable) until it's got several data points to
use when picking a new table size.  A more clever algorithm would be nice,
but this eliminates the worst of the problems.

The fix is to either get a more current copy of C News or just be patient
and wait for steady state.  (That can take quite a bit of patience if you
keep a lot of news on-line, mind you.)
-- 
"We're thinking about upgrading from    | Henry Spencer @ U of Toronto Zoology
SunOS 4.1.1 to SunOS 3.5."              |  henry@zoo.toronto.edu  utzoo!henry