Re: Hardware for 200GB+ DB ?
Date: 22 Dec 1994 10:21:44 GMT
Message-ID: <3dbjvo$cj7_at_mrnews.mro.dec.com>
In article <3d642h$h7i_at_fido.asd.sgi.com>, darrylr_at_wombat.engr.sgi.com (Darryl Ramm) writes:
...
|>>SAY WHAT ?
|>>What real life personal experience makes you say that OSF/1 scalability
|>>is 'just awfull' ??
|>
|>I talk to your customers. Not only does it not scale well but the SMP
|>version has been buggy. One financial institution comes to mind, but
|>then they are replacing DEC with Sun. Does DEC have any database
|>customers running OSF/1 on large SMP systems ? We have had trouble
|>finding them. Anybody out there on the net ?
|>
you repeat yourself. Be more specific. What exactly is buggy or does not scale?
Having spoken to one or so customer with a problem does not qualify to a
generic statement like you do.
I happen to just come back from a customer that uses one of our 'buggy,
unscalable' osf/1 systems to (file-)serve a bunch of IRIX systems. Quote
from the customer's system manager: 'if only IRIX would be as stable and
reliable as OSF/1'. What now? Does this qualify to shout out that IRIX is
buggy and unreliable. I don't think so, i never would dare to generalize
on this basis.
|>>On SPECrate benchmarks DEC OSF/1 systems scale up approx. linearly up to
|>>6 processors (which is the max nbr of processors for now, new announcements =
|>>biz.dec.announce, watch it).
|>
|>I'll ignore getting into a comparison based on SPECrate, it is just
|>*not* interesting for database workloads. I really hope that DEC does
|>not represent it to customers as such. It tests none of the operation
|>between an RDBMS engine and the operating system and hardware, neither
|>does it stress critical subsystems like I/O or networking (look at the
|>rates we measured during a TPC-A below). Databases are also
|>pathalogically worse at bus and cache bashing, a SPECrate does not even
|>get close.
|>
|>SPECrate is a CPU benchmark, remember I never disputed DEC has the
|>fastest processors around.
|>
Basically agree (especially on the statement on us having the fastest
processor :-)
Funny though that experience shows that for example the sizing of systems
to run the commerical SAP R/3 package (using Oracle as DB) nicely scales
along SPECrate(int).
|>>Also the DEC 7750 (5 cpus) won the AIM (tm) hot iron award as the best
|>>AIM multi-user benchmark performer they had so far (5-cpu scaling > 85%, show
|>>me better scaling for AIM benchmarks)
|>
|>I'd tend to weight AIM a lot less valuable than a real database
|>benchmark for evaluating performance or scalability. AIM stresses
|>certain subsystems and operating systems functions (like the filesystem
|>and scheduler) differently than a database benchmark. In fact tweeking
|>the filesystem and scheduler can produce dramatic changes in AIM
|>results, none of which help with real world large database
|>performance. Did the DEC result use any special filesystem or
|>scheduler hacks or tuning ? I have no idea if we even have a comparison
|>AIM number or are working on one.
All detailed info is in the full AIM disclosure report.
|>
|>If you want to throw useless numbers in here we just set a record for
|>the LADDIS benchmark, blowing away DEC, Sun and others. But so what ?
|>It's interesting if you run NFS, but has little to do with database
|>performance and scalability. If I could remember the LADDIS number I'd
|>mention it, but since it's not a database number I don't even bother to
|>remember it.
|>
|>>A DEC 7760 will perform in excess of 1000 tps, using ONLY 6 cpus, more than 50%
|>>of the result your system achieves with 31 (!!!) cpus.
|>
|>Firstly twice as fast is twice as fast. This discussion was about
|>supporting large environments, for the TPC-A twice as fast is also
|>twice as many users (around 20,000 tuxedo users in our case) and twice
|>the database size (we just over 400Gb of disk on-line, can't remember
|>the exact oracle db size). We produced twice the absolute performance
|>DEC did and we did this at slightly better price performance than
|>DEC. In fact the overall configuration starts to get to an interesting
|>size...
The point was to say that if a 6 processor Alpha is capable to deliver half of the performance of a 31 processor sgi that apparently our scaling can't be that bad.
|>
|> 31 R4400 150MHz CPUs
|> 1Gb Memory
|> 402 Gb disk
|> 20,497 Tuxedo users on the front end workstations
|> 4,300 2KB I/O's per second average
|> 6,000+ peak I/O's per second
|> 4,100-8,200 TCP packets per second.
|>
|>This benchmark was on 31 of our older (150MHz) CPU's, not the current
|>200MHz CPU's. Our TPC-A submission was a *gross* trade off where we
|>threw lots CPU's at the benchmark rather than spending more time
|>carefully tuning the database and OS as we needed to get a benchmark
|>result out. We ran with much more idle time than we should have,
|>confirming we could have tuned better.
|>
|>I mentioned Sequent as superior to DEC for scaling and high end
|>database performance. Some proof here is that Sequent TPC-B
|>results that represent similar sized workloads (unlike the TPC-A, the
|>TPC-B does not stress networking at all) to our TPC-A.
|>
|>And before I get flamed by anybody on the TPC, the results mentioned
|>here for DEC and Silicon Graphics are used for historical comparison.
|>They are no longer valid as they don't meet the latests TPC specs (most
|>TPC-A results also don't meet the current spec). We don't have any
|>plans to rerun these results.
True (regarding the validity of current results). We plan to disclose TPC-C results soon for OSF/1 platforms. Since (due to Oracle's dispute with the TPC) we had to change to another Database, this took longer than planned.
|>
|>>You might (or better as SGI DB Mktg Manager you should :-) read last weeks joint
|>>announcement between Oracle and Digital, announcing the largest in-memory
|>>database (8GB !) demonstration to achieve new levels of database performance.
|>>Of course run on a multi-processor, true 64-bit DEC OSF/1 system.
|>>(And really only possible there)
|>
|>As SGI DB Mktg Manager I have *much* better things to do than read
|>Digital press releases. Running an 8Gb database in memory is an
|>interesting trick but do people really care ? Who is going to purchase
|>this ? And in the context of discussing 200Gb databases 8Gb is a little
|>on the small side. Maybe I'm missing something since I'm just a dumb
|>marketing dweebe.
|>
I certainly don't expect you to read Digital press releases but thought you might read those of Oracle (since Oracle sent this one out). Also for a 200GB DB, a 8GB big Oracle SGA may speed up things compared to having a <1GB SGA for the same DB (at least that is what Oracle hints in its press release when saying that they see epeed improvements of 600-800% using this large SGA)
|>Silicon Graphics has been shipping systems for the high performance
|>(supercomputer) computing market for around two quaters now with a 64
|>bit operating system and up to 18CPU's and 16Gb of memory. So we know
|>a fair bit about 64 bit OS's. Frankly for most customers 64 bit UNIX is
|>not that exciting. DEC promotes it so proudly, but mostly it's a
|>solution looking for a problem. Real database technology that exploits
|>64 bits is a way away yet.
Don't be too sure about that. I suggest you ask Oracle when they are going to allow one of their next 7.1 releases on OSF/1 to take advantage of large memory configs.
|> File systems is one issue where handling
|><2Gb files can be a hassle, we (and other vendors ?) provide file
|>system that support larger files and volumes (we do about 1,000Tb now,
|>if you can find the disk for it). Main memory support >2Gb or >4Gb
|>(depending on the vendor) is another advantage of 64 bit but most
|>customers don't need that today. DEC's "bullet train" vs "steam train"
|>advanced UNIX advetisement is a joke. DEC bet badly on the wrong horse
|>in going to OSF/1
Luckily a by now large and rapidly growing customer base (especially here in Switzerland) does not share your view. And guess what, most of them are in the commercial computing area and use databases. As a technology guy i think it was a wise decision to chooes a UNIX(tm) implementation that is modern (Multithreaded Microkernel Technology). If you read some of the more current reports of companies like Gartner Group, Yankee Group, D.H. Brown Associates and others, you'll find that they give absolute top ratings to the current OSF/1 implementations, in the standards compliance area, commercial computing capabilities aso.
|> and they upset many Ultix customers (I was an Ultrix
|>customer once) by churned them to OSF/1. DEC's large benchmark results
|>are on OpenVMS *not* OSF/1, for the smaller benchmarks there is some
|>proof on similar sized systems that OSF/1 systems are around 20% or so
|>slower than a similar system running OpenVMS. I'll try to dig out the
|>numbers if anybody is interested.
|>
|>>So in the future pls refrain from bashing other vendors, in my opinion
|>>it's bad style.
|>
|>Sorry, I know it must be tough being at DEC nowdays.
Not as tough as you may wish, at least here in Switzerland where Digital always did very well and where Digital is the undisputed number two computer company.
MatthiasD.
DEC Digital Equipment Corp. AG, Switzerland Matthias Dolder
..still speaking for myself and not for Digital... Received on Thu Dec 22 1994 - 11:21:44 CET