Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!simtel!swidir.switch.ch!newsfeed.ACO.net!Austria.EU.net!EU.net!news.sprintlink.net!news.seanet.com!news.seanet.com!michaelv
From: michaelv@MindBender.HeadCandy.com (Michael L. VanLoon)
Newsgroups: comp.unix.bsd.freebsd.misc
Subject: Re: "An HTTP software server can pummel a CPU..."
Date: 15 Sep 1995 06:04:34 GMT
Organization: HeadCandy Associates... Sweets for the lobes.
Lines: 69
Message-ID: <MICHAELV.95Sep14230434@MindBender.HeadCandy.com>
References: <gary-1309951409030001@bhb17.acadia.net> <438u8f$cok@kadath.zeitgeist.net>
<439qed$rdm@lace.Colorado.EDU> <43aohc$89j@nimitz.fibr.net>
NNTP-Posting-Host: mindbender.seanet.com
In-reply-to: Rob Snow's message of 15 Sep 1995 02:31:08 GMT
In article <43aohc$89j@nimitz.fibr.net> Rob Snow <rsnow@txdirect.net> writes:
apuzzo@snake.colorado.edu (Tony Apuzzo) wrote:
>In article <438u8f$cok@kadath.zeitgeist.net>,
>Amancio Hasty, Jr. <hasty@rah.star-gate.com> wrote:
>>gary@first.acadia.net (Gary Robinson) wrote:
>>>"An HTTP software server can pummel a CPU, because there's no mechanism in
>>>any existing server to control the amount of processor time allotted. Ten
>>>users doing SQL questies, for instance, might bring the system to a
>>>standstill while users trying to receive static pages wait."
>>Yeap , this is very true for OSes which don't have priority pre-empted
>>scheduling. For instance, right now I am running a simple program which
>>has a tight loop just chewing up the cpu while I am typing this.
>>Wait let me start five more copies...
>>So much for InfoWorld.
>You're missing the point Try this instead:
> sh$ for i in 1 2 3 4 5 6 7 8 9 0
> > do
> > find / -type f -exec grep slow '{}' \; 2>&1 >/dev/null &
> > sleep 5
> > done
>This is a more realistic (though still pretty poor) simulation of 10 users
>doing complex SQL queries.
>This type of thing can only happen if your HTTP server is serving pages
>that support search engines. If you have other users trying to get regular
>pages (html code, .gif's, etc.) they will be *significantly* delayed while
>this is going on. It is possible to avoid problems like this through load
>balancing, or running the SQL on another machine, etc. I think Infoworld's
>point was that it is easy to slow an otherwise capable HTTP server to a
>crawl if you aren't careful.
Maybe I dont quite understand this, but how about starting your SQL
queries with a high nice level?
ie. In the above example:
nice +15 find...etc...
My machine is almost always running a couple of processes doing time series
analysis and I just run them nice +15 - +20.
I don't think the CPU utilization is the big factor in a heavy-hit
database server -- that would be disk, and I/O.
I'll bet you could still get decent user response if you had a
medium-speed CPU (fast 486 or slower Pentium), coupled with a PCI bus,
and (the key ingredient) put all of the database stuff on one or more
drives connected to a PCI SCSI controller (or two), then put a
completely separate PCI SCSI controller in the machine and attach the
user drives to that one. I'll bet a modern OS would be usably
responsive under such conditions.
Most of the database processes would be spending their time sleeping,
waiting on a disk event, freeing up CPU for normal users. And, since
the normal users wouldn't be fighting the SCSI accesses for I/O, being
on their own disk and controller, response would be adequate.
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Michael L. VanLoon michaelv@HeadCandy.com
--< Free your mind and your machine -- NetBSD free un*x >--
NetBSD working ports: 386+PC, Mac 68k, Amiga, HP300, Sun3, Sun4,
DEC PMAX (MIPS), DEC Alpha, PC532
NetBSD ports in progress: VAX, Atari 68k, others...
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -