Re: Hardware for 200GB+ DB ?
Date: 18 Dec 1994 06:05:09 GMT
Message-ID: <3d0jel$faf_at_fido.asd.sgi.com>
In article <3d07lt$l08_at_moon.earthlink.net>,
Bob Stewart <bob_at_musem.earthlink.net> wrote:
>smith117_at_delphi.com wrote:
>: If you are looking for the highest capacity technology,
>: SGI or DEC have the best stuff today.
>:
>: IMHO, and be careful how anybody configures your system. Lot's of hidden
>: expandability barriers that require box swaps!!
>:
I'll agree with that, one vendor comes to mind, lots of configurations of one and two CPU systems, but look out for the cost when you have to do a BBBIIIIGGGGG expensive forklift upgrade to get to a "real" SMP system.
>Thanks for the comment, Dan. But why? What makes SGI or DEC special?
>SGI has fast graphics, but they have specialized graphics hardware,
>and often use 8bit hardware at that to get speed. I have no knowledge
>of their ability to handle large DBs. Same with DEC. I've heard of
>them, they're big, but so is IBM. What specifically makes either of
>these vendors worth my $350k?
More completely biased information from the hardware vendor, but since you asked....
o Up to 36 MIPS R4400 200MHz CPU's with 4Mb cache each. o 1.2GB/sec sustained memory bandwidth o 1.2GB/sec sustained aggregate I/O bandwidth o Fat (100MB/sec sustained) I/O sub-channels o Up to ~7TB RAID storage o 2GB main memory o US list prices start a ~ $140k for the big CHALLENGE-XL 2-36 CPU system. We have 1, 1-4, and 2-12 CPU systems at lower prices.
I expect that many of our graphics systems ship with well above the base 8 bit colour support, which is only available on the very low end systems. As you point out fast graphics has lots to do with hardware for line and polygon drawing, z-buffering and texture mapping. The graphics hardware per se has nothing to do with our fast database performance, however the base reqirements designed into our I/O, CPU and memory subsystems that enable our systems to support such fast graphics do help make a good database server. For our high end Onyx graphics supercomputers we have to be able to move around a massive amount of data between the CPU's, memory and the RealityEngine2 graphics engines. BTW the RealityEngine2 does around 300k polygons per second and it's definitly *not* 8 bit color ! Database workload was also specificaly considered during the design our current server architecture, that has been shipping for around two years now. The base server architecture forms three product families, the Onyx graphics supercomputers (R4400 + RealityEngine), the PowerCHALLENGE numerical supercomputers (R8000) and the CHALLENGE (R4400) database, digital media and file servers.
CPU-PERFORMANCE
Our systems ship today with up to 36 MIPS R4400 CPU's running at 200MHz. The 36 processor system, with up to 2GB of memory is about the size of a typical home refrigerator. Each processor is ~140SPECint. Processor boards have 4CPU's each and 4 MB of secondary cache per CPU (that's 144Mb of cache in a high end system). The large seconday cache really helps database performance. These CPU's put us around the processor performance of the HP T500 on a CPU for CPU basis and well in front of Sun or CRAY's 6400. CPU for CPU DEC Alpha is faster, but due mostly to OS issues (and you have a choice of OS' :-) ) their systems do not scale up well. If you care about futures we recently announced the R10000 processor. The R10000 has an estimated ~300 SPECint/~600SPECfp performance. Database performance will be good thanks to features like speculative branch execution, two way set associative cache, 32Kb primary I Cache, up to 16Mb of unified seconday cache. R10000 begins sampling early next year.
CPU-MEMORY BUS SPEED
The main reason that Oracle scales up on many CPU's so well on our systems is the high CPU-memory bus speed. Databases really hammer the bus. Our 2,000+tps benchmark was done with 31 CPU's, we would not have run that many if there was not a performance return on the CPU cost. CHALLENGE servers have 1.2GB/sec *sustained* CPU-Memory bandwidth (about 2GB/sec peak). Around twice the speed of the fastest that DEC or HP can do, or over three times the speed of the Sun SS2000. The only thing that comes close in memory bandwidth is the Cray 6400.
I/O PERFORMANCE
We have the fastest I/O in the industry. The deskside servers support up to 3 PowerCHANNEL2 controllers, each can *sustain* 320MB/sec of I/O for a total of 960MB/sec. Each PowerCHANNEL can support multiple SCSI-II F/W buses, Ethernet, VME (for slow things like X.25 and SNA). High speed networking like FDDI, HIPPI and ATM is supported through PowerCHANNEL2 daughtercards on 100MB/sec sustained sub-channels. The CHALLENGE-XL rack server supports up to 4 PowerCHANNEL2's and can sustain up to 1.2 GB/sec of I/O. The competition here is pathetic. The number of drives that you can plug into many of these systems and what they can really deliver in I/O is a different matter. Don't get suckered I/O bandwidths by taking the large number of SCSI busses on a HP T-500 or Sun SS2000 system and try to aggregate them all together. The T-500 has 8 I/O channels that *peak* at a whopping 32MB/sec each. Giving a *peak* aggregate bancdwith of 256MB/sec, your milage will be a lot less. Each channel would have trouble sustaining the sequential I/O capability from more than one SCSI-II F/W bus !
Parallel query database technology is starting to drown many of the systems out there that may run fine doing random 2KB I/O's. Watch out when you start trying to scale up with Oracle 7.1 type parallel technology. Also as people move towards fast networking many of these systems slow I/O controllers and buses will really get in the way. Try doing 100MB/sec on HIPPI or ATM when your I/O controller peaks at 32MB/sec or 50MB/sec ! I believe we measure about 80MB/sec per HIPPI connection to a mainframe and we are not the bottleneck !
The I/O susbsystem we are shipping today will easially support R10000 based systems and several more generations of faster disk drives. One University research group has measured over 500MB/sec from a disk array to memory on a CHALLENGE system running a non-database workload. I can dig out the white paper for those interested. The same I/O technology allows us to use our general purpose systems as high end digital media servers.
I/O CAPACITY
Our deskside systems support up to around 4TB RAID (they stop being "deskside" around a few 100 GB :-) ) and the larger rack CHALLENGE-XL system supports around 7TB. For non-RAID storage we support up to 512 SCSI-II F/W devices. We ship both 2GB and 4.3GB 7200rpm SCSI-II F/W drives. We also support just about every tape drive from Cartridge, DAT, DLT, 3480, 9 track, 8mm, stackers and the big silos as well as most popular backup and archive products so you have some chance of backing up and recovering these big systems.
>In addition, would you recommend that I go with these vendors arrays,
>or go with some, specific, third party?
You can use ours or a third party's. Obviously we would prefer you to purchase complete systems, but we try to make it easier to use whatever you want.
>Bob Stewart (KB9ZW)
>wk USA (310) 335-7152
Cheers
Darryl
-- Darryl Ramm Silicon Graphics Database Marketing Manager 2011 North Shoreline Blvd. darrylr_at_sgi.com Mountain View, CA, 94039-1389 voice: (415) 390-2875 fax: (415) 390-6320Received on Sun Dec 18 1994 - 07:05:09 CET