Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!news.rmit.EDU.AU!goanna.cs.rmit.edu.au!news.apana.org.au!cantor.edge.net.au!news.teragen.com.au!news.access.net.au!news.mel.connect.com.au!news.syd.connect.com.au!phaedrus.kralizec.net.au!news.mel.aone.net.au!news.netspace.net.au!news.mira.net.au!pumpkin.pangea.ca!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!cam-news-hub1.bbnplanet.com!cpk-news-hub1.bbnplanet.com!news.bbnplanet.com!rill.news.pipex.net!pipex!dispatch.news.demon.
net!demon!newsfeed.nacamar.de!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: 13 Mar 1997 11:20:54 -0800
Organization: BEST Internet Communications, Inc.
Message-ID: <5g9k2m$c68@flea.best.net>
References: <331BB7DD.28EC@net5.net> <5g76gb$6c6@flea.best.net> <3327BBF9.784A@earthlink.net> <5g90sg$aj6@innocence.interface-business.de>
NNTP-Posting-Host: flea.best.net
Lines: 75
Xref: euryale.cc.adfa.oz.au comp.unix.sco.misc:36611 comp.unix.bsd.freebsd.misc:37059 comp.unix.bsd.bsdi.misc:6325 comp.sys.sgi.misc:29124
:In article <5g90sg$aj6@innocence.interface-business.de>,
:J Wunsch <joerg_wunsch@interface-business.de> wrote:
:>fastbit@earthlink.net wrote:
:>
:>> I don't understand your analysis here. If the CPU is idle and the disks
:>> are going like crazy, it's not that the CPU is too fast -- it's the I/O
:>> that's too slow.
:>
:>Where ``I/O too slow'' sometimes means that simply your users are too
:>slow to even request the data. :-)
:>
:>--
:>J"org Wunsch Unix support engineer
:>joerg_wunsch@interface-business.de http://www.interface-business.de/~j
Heh. The most common mistake that people make when figuring out
I/O requirements is in their assumption that, somehow, magically,
hard drives will respond instantly to read and write requests. This
is only true for LINEAR read and write requests.
For anything outside of video processing, I/O requests to hard drives
will involve a certain amount of seeking. The seeking reduces that
11 MBytes/sec linear transfer rate you get from a modern HD to something
far less under load. This is why you can throw 30 disks onto a PCI
bus without saturating the PCI bus.... the choke point isn't the bus,
it's the SCSI controller's maximum transaction rate and the disk
seek latency.
Here's an example: news1.best.com:
news1:/news> iostat 1
tty sd0 sd1 sd2 fd0 cpu
tin tout sps tps msps sps tps msps sps tps msps sps tps msps us ni sy in id
0 12 -2 49 0.0 -2 66 0.0 3 53 0.0 0 0 0.0 9 4 17 5 65
0 82 248 17 0.0 347 52 0.0 581 86 0.0 0 0 0.0 17 0 15 8 60
0 81 480 27 0.0 721 82 0.0 803 80 0.0 0 0 0.0 12 0 27 5 56
0 81 441 30 0.0 449 64 0.0 1042 90 0.0 0 0 0.0 15 0 16 3 66
0 81 175 11 0.0 928 86 0.0 700 91 0.0 0 0 0.0 20 0 16 10 54
news1:/news> vmstat 1
procs memory page disks faults cpu
r b w avm fre flt re pi po fr sr s0 s1 s2 f0 in sy cs us sy id
544 0 685.1 11.1 81 28 1 0 73 60 49 66 53 0 8 643 737 13 22 65
222 0 680.8 11.3 157 19 13 0 91 0 50 48 69 0 2145 4087 1039 15 25 60
1527 0 685.1 11.5 88 13 6 0 101 0 27 79 80 0 2082 3488 971 14 27 59
news1:/news> netstat -in 1
input (Total) output
packets errs bytes packets errs bytes colls
747 0 232977 1113 0 848970 445
556 0 99767 759 0 587120 297
652 0 132563 938 0 653623 403
690 0 169295 1100 0 943795 445
653 0 148440 1097 0 823143 489
557 0 124918 992 0 659356 359
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).
In fact, I can't really expand this machine any more without adding
memory... bumping the 128MB of ram to 256MB or 512MB.
Do I need a faster cpu in this box? No. Do I need a faster I/O bus?
No. In fact, I will probably run out of memory long before I
run the machine into the ground cpu or I/O wise.
-Matt