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