Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!news.cs.su.oz.au!metro!metro!munnari.OZ.AU!news.ecn.uoknor.edu!feed1.news.erols.com!cpk-news-hub1.bbnplanet.com!cam-news-hub1.bbnplanet.com!news.bbnplanet.com!howland.erols.net!newsxfer3.itd.umich.edu!news1.best.com!nntp1.ba.best.com!not-for-mail
From: dillon@flea.best.net (Matt Dillon)
Newsgroups: comp.unix.sco.misc,comp.unix.bsd.freebsd.misc,comp.unix.bsd.bsdi.misc,comp.sys.sgi.misc
Subject: Re: no such thing as a "general user community"
Date: 18 Mar 1997 14:17:03 -0800
Organization: BEST Internet Communications, Inc.
Lines: 64
Message-ID: <5gn48v$8ds@flea.best.net>
References: <331BB7DD.28EC@net5.net> <5g90sg$aj6@innocence.interface-business.de> <5g9k2m$c68@flea.best.net> <332E37FB.234D@OntheNet.com.au>
NNTP-Posting-Host: flea.best.net
Xref: euryale.cc.adfa.oz.au comp.unix.sco.misc:36934 comp.unix.bsd.freebsd.misc:37427 comp.unix.bsd.bsdi.misc:6401 comp.sys.sgi.misc:29308
:In article <332E37FB.234D@OntheNet.com.au>,
:Tony Griffiths <tonyg@OntheNet.com.au> wrote:
:>Matt Dillon wrote:
:>>
:>Interesting stats... Our news server is also HORRIBLY i/o bound. I
:>added
:>some more ram which helped but the disks are still the bottleneck!
:>
:>I've toyed with the idea of mounting the news filesystems 'async' to see
:>what affect that would have although I'm a little afraid of what the
:>result would
:>be if the system crashed! Can anyone who has done this recommend async
:>mounting
:>as a reasonable solution to increase i/o thru-put?
:>
:>> So, here the machine's cpu is sitting 60% idle, with the 10BaseT
:>> maxed out and two of the three disks almost maxed out (modern disks
:>> tend to max out at around 100 transactions/sec with moderate seeking).
:>> Less then 5% of the cpu is being used by the interrupts generated by
:>> all of this junk, and less then 10% of the I/O bus's bandwidth is
:>> being used. The only reason the machine is 60% idle rather then 90%
:>> idle is due to the fact that there are over 250 *active* processes
:>> running on it (supporting 80 or so newsfeeds, in this case).
:>
:>It's also interesting that your Ethernet has a high collision rate as
:>does
:>ours. A switching hub is going in over the next day or so with each
:>server
:>having a dedicated (full-duplex) port which will hopefully improve
:>things!
:>
:>Tony
Naw, that's normal when one is saturating an ethernet segment with
outgoing traffic in the face of incoming traffic. They are mostly
single-backoff collisions due either to the incoming traffic or
due to short term saturation of the FDDI backend on the switch. It's
the switch's way of flow controlling the link without causing packet
loss. This is very different from the multi-backoff collisions you
get when the collisions are due to too many nodes on the physical
ethernet segment.
Different switches do different things. I admit that the collision
rate is a bit higher then I would expect, but it's still quite reasonable.
If I average the numbers out over 10 second blocks, it becomes
obvious:
news1:/news> netstat -in 10
input (Total) output
packets errs bytes packets errs bytes colls
5687 0 1906758 7688 0 4587742 2593 (649K/sec)
5894 0 2951019 7001 0 4304987 2620 (725K/sec)
5599 0 2944680 6539 0 3231797 2258 (617K/sec)
4668 0 2098160 5755 0 3428171 1719 (552K/sec)
5753 0 1184580 7739 0 5273506 2606 (645K/sec)
etc..
If you look at the first line, you have (in a 10 second period) 5687 + 7688
packets on the wire with 2593 collisions. So that's 1337 packets/sec on
the wire.
-Matt