🚀 go-pugleaf

glenn> The disk is doing as many I/Os per second as it can, but the incoming
glenn> NNTP feeds are backloged and not catching up noticably.  My solution to
glenn> this; split /usr/spool/news over multiple partions.  But this prompts
glenn> my question: Has anyone done any investigation into layout policies for
glenn> I/O efficient multi-partition news spools?  Any serious speculation or
glenn> real world experience?

   Our news spool is spread over two disks on separate controllers,
and it helps.  We get all the standard hierarchies, plus alt and gnu.
In deciding how to divide the hierachies across disks, I considered
their relative sizes, along with their local popularity according to
arbitron (INN can give you great newsgroup access statistics, too).  I
settled on putting alt and rec on one disk, and everything else on the
other.  The news software, including history, logs, and the mthreads
database, are on a third disk.  Swap space is divided between both the
third disk, and a fourth disk that otherwise isn't used for news.

   What?!  Not everybody has four disks on their news systems?  Don't
tell me: you only have one CPU, too?  :-) :-) :-)

   This has appeared to balance the I/O load reasonably well across
the two news disks.  The third disk is only heavily used when mthreads
runs.  The disk space used is also relatively well balanced, even
though everything expires at the same rate (we don't get a.b.p.e., so
maybe that slants things a bit :-).

glenn> The reason I think this is an issue is that to read an article via a
glenn> sym-link name costs 2 I/Os instead of 1, negating part of the benefit
glenn> of using 2 disks.  This tells me that to maximize performance, I must
glenn> minimize the number of reads by symlink name.  A good heuristic to
glenn> achieve this is to minimize the number of symlinks.

   I worried a bit about symlink overhead, but figured it wouldn't be
as significant a detriment as the double disks would be a benefit, and
that filesystem cacheing might offset it somewhat.  I don't know how
you'd come up with an algorithm to minimize symlinks, as crossposting
seems to me to be largely unpredictable.  Which disk would you put
alt.flame on?  :-)

--
David Myers                                             (513) 865-1343   
Mead Data Central           No news is             Fabrication Systems
P.O. Box 933                 bad news.                dem@meaddata.com
Dayton, Ohio  45401                             ...!uunet!meaddata!dem