Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.bhp.com.au!mel.dit.csiro.au!munnari.OZ.AU!news.ecn.uoknor.edu!solace!nntp.uio.no!news.cais.net!news.jsums.edu!gatech!newsfeed.internetmci.com!uunet!not-for-mail From: kls@MAILBOX.SLAC.Stanford.EDU (Karl L. Swartz) Newsgroups: comp.unix.bsd.freebsd.misc,news.admin.technical,news.software.nntp Subject: Re: Poor performance with INN and FreeBSD. Date: 9 Apr 1996 11:52:20 -0400 Organization: Stanford Linear Accelerator Center Lines: 63 Sender: zorch@ftp.UU.NET Approved: zorch@uunet.UU.NET Distribution: world Message-ID: <DpHI0o.2A6@unixhub.SLAC.Stanford.EDU> References: <311F8C62.4BC4@pluto.njcc.com> <4go23v$8hp@fozzie.sun3.iaf.nl> NNTP-Posting-Host: ftp.uu.net Xref: euryale.cc.adfa.oz.au comp.unix.bsd.freebsd.misc:16805 news.admin.technical:1394 news.software.nntp:21400 In article <4ipb5c$24om@usenetw1.news.prodigy.com>, bill davidsen <davidsen@tmr.com> wrote: >Why are you worried about batch and unbatch, or feed times? Are you >really running a news server with enough news to be a problem and >few enough readers that they are NOT the problem? I'm worried about batch and feed times because they're the critical path. A full feed is around 750,000 or more articles per week. If you take one second to process each accepted article (never mind the ones you reject), you're screwed, because there aren't 750,000 seconds in a week. Hopefully there's some parallelism with multiple feeds, but you still don't have a lot of time. Readers don't have nearly the volume. I look at a handful of groups and, of the stuff offered from NOV data, I might look at a few hundred. Say 500 articles, an exceedingly generous amount. If it takes a second or two to pull up each article, I might get mildly cranky, not nothing dire will happen. If there were 100 readers on the system who were as active as I am, that's still only 50,000 articles being read per week, not even 10% of the total flowing through the system. >Having run on a log filesystem (JFS on AIX), I can tell you that the >log file is the bottleneck. To get performance up, first I put the >logfile on a dedicated disk (cut expire time by 3), and then on a >dedicated solid state disk (cut expire time by 3 again). As Peter correctly noted, AIX's JFS is not a log-structured filesystem. It's a fairly conventional filesystem, with a separate journal which is log-structured. That's an entirely different animal. >| One of the attractions to >| the "toaster" is that you just throw more disk at it when necessary, without >| worrying about where exactly it should go. With disks being cheap and >| reduction in staffing being plentiful, that's very attractive. >Yes, but adding disk on striped filesystems is not generally easy, >and the performance hit by not striping, at least for readers, is >just not acceptable. Who said anything about striped filesystems? True striping is foolish for news anyway -- it's forte is with large files, exactly the opposite of what you see with news. For news you'd want concatenation, and in that case it's generally pretty easy to add another disk. Right now I'm using Sun's OnLine:DiskSuite and adding a disk is trivial. You'll still get better performance than one larger disk, though not for one individual article. [My experience with concatenation vs. striping is at a variance with Karl's statement. Jerry Aguirre has posted on this issue in the past, and the upshot seems to be that striping does indeed work better for news. --mod] The Network Appliance "toaster" uses RAID 4 but adding a disk is even more trivial than with OnLine:DiskSuite. You plug in a 4 GB disk and tell the system to use it, and you've got an added 4 GB (minus some overhead). -- Karl Swartz |INet kls@unixhub.slac.stanford.edu SLAC Computing Services | or kls@chicago.com 1-415/926-3630 |UUCP uunet!lll-winken!unixhub!kls -or- ditka!kls (SLAC and the US Dept. of Energy don't necessarily agree with my opinions.)