Xref: utzoo comp.arch:4763 comp.databases:988
Path: utzoo!mnetor!uunet!mcvax!ukc!stl!stc!idec!alice!fox
From: fox@alice.marlow.reuters.co.uk (Paul Fox)
Newsgroups: comp.arch,comp.databases
Subject: Re: Unix machines for large databases
Message-ID: <347@alice.marlow.reuters.co.uk>
Date: 10 May 88 17:07:43 GMT
References: <428@cmx.npac.syr.edu>
Reply-To: fox@alice.marlow.reuters.co.uk (Paul Fox)
Organization: Reuters Ltd PLC, Marlow, Bucks, England
Lines: 30

In article <428@cmx.npac.syr.edu> billo@cmx.npac.syr.edu (Bill O'Farrell) writes:
>Help! By Friday we need to know if there is a Unix-based box that
>can work as a very high-performance data-base server.  Yes, there are a
>million Unix boxes out there, but a data-base server has to be able to
>cope with concurrent access by multiple (possibly several hundred)
>users.  Simple file locking isn't good enough -- users should never
>have to read "file locked" error messages.  Also, the disk performance
>should be very good.
>
I have no answers for you but I do have some questions ...

Is your database mainly for reads or reads and writes. If its mainly for
reading information, then having a large disk cache, (eg 8MB) will far
outweigh the speed of the disk.

If you really are going to try to support hundreds of users, then one
major problem will be finding a network interface that can reliably
support this many virtual circuits. One of the biggest problems with
all machines seems to be the limit on the number of concurrent sessions.
Not only is a large amount of memory (ie several K) needed per
session, but also one has to consider things like the size of the
ARP tables.

=====================
     //        o      All opinions are my own.
   (O)        ( )     The powers that be ...
  /    \_____( )
 o  \         |
    /\____\__/      
  _/_/   _/_/         UUCP:     fox@alice.marlow.reuters.co.uk