Re: Hardware for 200GB+ DB ?

In article <3d46g9$856_at_mrnews.mro.dec.com>, Matthias Dolder <matthias_at_ares.zuo.dec.com> wrote:
>
>In article <3d01k4$2pm_at_fido.asd.sgi.com>, darrylr_at_wombat.engr.sgi.com (Darryl Ramm) writes:
>|>In article <singerap.43.000D72EF_at_powergrid.electriciti.com>,
>|>Paul Singer <singerap_at_powergrid.electriciti.com> wrote:
>|>>In article <5Y00H0C.smith117_at_delphi.com> smith117_at_delphi.com writes:
>|>>>From: smith117_at_delphi.com
>|>>>Subject: Re: Hardware for 200GB+ DB ?
 

>|>>>If you are looking for the highest capacity technology,
>|>>>SGI or DEC have the best stuff today.
>|>
>|>Thanks for the SGI vote, however I might dispute DEC though and
>|>substitute Sequent or a few other vendors depending on what the CPU,
>|>I/O and memory capcity requrements where. DEC's OSF/1 scalability is
>|>just awfull and it's not clear they are doing much to fix it....
>
>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 ?

>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.

>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.

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...

	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.

>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.

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. 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 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.

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-6320