Sun breekt nieuw database snelheidsrecord

Sun heeft bekend gemaakt dat de Sun Enterprise 10000 'Starfire' server een nieuw TPC-C snelheidsrecord heeft gehaald in de categorie voor single-system servers. De Starfire doos trok 156.873 transacties per minuut en neemt daarmee de troffee over van IBM's AS/400E, die net iets minder snel was met 152.346 tpmC. Het Sun systeem draaide op 64 400MHz UltraSparc II processors en beschikte over 64GB geheugen. Solaris 7 werd als OS gebruikt en Sybase ASE fungeerde als database server:

Flexing the muscle that has made it the undisputed champion of the high-end UNIX® server realm, Sun Microsystems, Inc. (Nasdaq: SUNW - news) today announced that a Sun Enterprise(TM) 10000 server smashed the world record for single-system performance on the TPC-C benchmark by registering 156,873.03 transactions per minute (tpmC) running Sybase Adaptive Server Enterprise (ASE) at a very economical $48.81 price/tpmC. Continuing its longtime performance leadership, the Sun Enterprise 10000 server, popularly known as the Starfire(TM) server, has set or reset 40 benchmark records in its storied four-year history.

According to International Data Corp., the Starfire accounted for 51 percent of the high-end UNIX servers shipped in the first quarter of calendar year 2000. In stark contrast, IBM accounted for a meager 5 percent of shipments during that same period and Hewlett-Packard 23 percent. Unequaled scalability and abundant RAS features, such as Dynamic System Domains, Inter Domain Networking, dynamic reconfiguration and alternate pathing, have kept Sun's flagship server in a league of its own.

[...] Established by the Transaction Processing Council, the TPC-C benchmark is an industry-standard test designed to measure systems' online transaction processing capacity under controlled conditions.

On the TPC-C benchmark, Sun's flagship Starfire server delivered an overwhelming 156,873.03 transactions per minute (tpmC) running Sybase ASE and a highly competitive price/performance mark of $48.81 price/tpmC. The system, running Sybase release 12.0.0.2 and the Solaris(TM) 7 Operating Environment, was configured for this benchmark with 64 UltraSPARC(TM) II 400 MHz CPUs, each with a 8 MB external cache, and 64 GB of internal memory combined with 36 StorEdge A5200 disk arrays and eight Sun StorEdge(TM) T3 disk arrays totaling 15.5 TB of storage. The configuration is scheduled to be available February 28, 2001.

Reacties (38)

[ShadowLord]

by registering 156,873.03 transactions per minute (tpmC) running Sybase Adaptive Server Enterprise (ASE) at a very economical $48.81 price/tpmC.

OK. 156873,03 * $48.81 = $7656972,59
Zo'n slordige 7,5 a 8 miljoen dollar voor een databees servertje dus. En dat noemen ze economisch?

Ik weet niet hoor, maar weet iemand een applicatie waarvoor je een DB server nodig hebt die dat kan (156873,03 tpmC).
Ik bedoel, ben je over het algemeen niet een beetje goedkoper uit met meerdere, minder snelle DB servers?

[Fevida]

Tuurlijk kan die TCO (Total Cost of Ownetship) lager. Ga maar eens naar Compaq.com en neem een kijkje bij de Alpha beesten draaiende op True64 UNIX.

[EfBe]

1) Een banksysteem dat snachts alle landelijke transacties verwerkt. (en dat moet dus wel klaar zijn binnen een bepaalde tijd!)
2) De belastingdienst met een systeem waar _ALLE_ nederlanders in zitten met al hun financiele gegevens. Dit is ZOVEEL data, dat je wel snelle machines nodig hebt)
3) Getronics die ERG veel creditcard transacties van nederland verwerken met aardige grote servertjes
en zo zijn er nog wel een groot aantal zaken op te noemen

Nu is 8milj $ wel veel. Als je kijkt in de lijst van TCP-C scores/systems, dan zie je dat er andere OPLOSSINGEN zijn: clusters van IBM en Compaq bv, sneller (veeeeel sneller) en goedkoper (de helft!).

Daar zitten ook nadelen aan hoor: als een system in een cluster plat gaat heb je kans op transactieverlies (bij transacties die over meerdere servers zijn verdeeld), of iig snelheidsverlies (wanneer de transaction coordinator software de crash van de node eidenlijk oppikt en de transactie opnieuw moet worden verdeeld over het cluster. Kost relatief meer tijd dan in een enkel system). Binnen 1 enkel system zoals deze broodrooster van Sun niet, omdat alle processoren in hetzelfde memory zitten te vrotten. Uiteraard heb je met een 1 enkel system weer nadelen vwb dat het maar 1 system is en dus erg veel warmte produceert, relatief duur is tov concurrenten met clusters, en vergt specialistische software en beheer.

Je ziet hier dat Sun duidelijk geen antwoord heeft op het distributed computing model van Windows2000. De dagen dat Central Computing de methode was om met grote blokken data om te gaan, is nu wel over. Ik snap ook niet waarom Sun de TCP-C test, die ECHT veel geld kost!, niet heeft uitgevoerd op meerdere sparcstations in een cluster. Maar wellicht hebben ze dit geldverslindende monster onder de aandacht willen brengen. Nu nog hopen dat ze de bug in hun memory weten op te lossen

[Verwijderd]

ja, een die onder windows draait om de fouten eruit te halen

[arnob]

hmm, beetje typisch hoor. 'Single system' maar met 64 (!) procs.
Als ik kijk naar de andere resultaten zie ik ondermeer op nr.5 (1tje hoger) een Compaq cluster met in totaal 64 procs staan met 161719 transacties voor 21.86 US $ per transactie.
Dus sneller en goedkoper.

Oja, dat compaq cluster kost een 3,5 miljoen USD en dat Sun systeem maar liefst 7,5 miljoen USD!!

pff, marketing mensen

[Verwijderd]

Dit is idd. vals spelen, stop het in een kastje en verbind het met een bloedsneller databus aan elkaar draai er solaris op, en het wordt ingehaald door een aantal putertjes met een (1Gbps, maar das toch nog altijd minder b/w)
aan elkaar gelust, maar dat teld dan weer niet omdat het niet in een doosje zit

[Verwijderd]

Da's geen vals spelen, da's een parallele cluster-computer. Die heb je in alle soorten en maten, en zijn ook wel bekend onder de naam BeoWulf. Ooit ontwikkeld door de NASA wegens geldgebrek (jaja, ook daar al )! Er zijn er inmiddels al heel wat van gebouwd c.q. in elkaar geknutseld, varierend van 160 stuks Alpha-264 processoren tot 600 (!) 486's/Pentium-I's etc door elkaar heen (en ja, dat ding rekent ook nog!

Voor meer info: www.beowulf.org

Kun je daar ook meteen de (Linux-) software downloaden om er zelf ook eentje in elkaar te knutselen

[EfBe]

1 systeem met een interne databus is geen 'beowulf' cluster. Beowulf is gewoon een techniek voor delegatie van brokken werk en heeft dus NIETS met een hardwarematige oplossing te maken vwb interne systeemstructuur.

[Verwijderd]

Twee kleine opmerkingen van mijn kant dan maar:

1 - ik had 't over de computer die in dit specifieke geval genoemd werd, da's volgens mij namelijk wèl een beowulf, but correct me if i'm wrong!

2 - 't maakt natuurlijk niet uit hóe je het doet, het gaat er om hoe de handel presteert, dus of je dat nu met interne databus of gigabit netwerk doet maakt op 't einde niet meer uit toch? Wat telt is het resultaat, en vooral price/performance

[Verwijderd]

Hmmm... Zo'n Sun doos is inderdaad een leuk speeltje, en die dynamic system domains zijn heel erg cool, maar om nu direct te stellen dat het apparaat een "league of its own" heeft is wel een beetje overdreven.

Uit de 1999 Operating System Function Review van www.dhbrown.com :
"Solaris 7 captures the lead for overall scalability, supporting a very broad SMP range, offering strong 64-bit capabilities, and holding competitive ratings in other areas. IRIX 6.5 follows closely; it also offers a very broad SMP range, but lacks performance evidence for its database clustering options."

Overall eindigd Solaris achter AIX, Tru64 en HP-UX.

[Vuurvlieg]

Er zijn genoeg instellingen die deze server goed kunnen gebruiken. Ga maar eens na hoeveel transacties er bij banken gedaan moeten worden. Dat zijn er echt geen schamele 150.000 per minuut, die kunnen wel meerdere van die systemen gebruiken. Bovendien internationale beurzen als de amsterdam exchanges kunnen zulke systemen ook wel gebruiken. En dit zijn de single server systemen he.. Er worden dus ook hele gedistribueerde systemen van op elkaar afgestemde single server systemen verkocht. Bovendien als je systeem een dergelijke grote hoeveelheid aan transacties moet verwerken wordt er flink verdiend. Dus qua geld moet het ook wel lukken lijkt me.

[tazitiz]

Wat ik hier niet opmerk is dat iedereen het er over eens is dat hoe meer processoren hoe sneller de machine is. Dit is zeker in het x86 geval niet zo. De ultrasparcs zijn met de risc instructieset en de originele sparc structuur al op ontworpen om in een computer geplaatst te worden met meer dan 4 processoren, maar die hele x86 lijn is dat niet. Bijvoorbeeld de pentium 2 die al sneller is dan de sparc in meerdere opzichten heeft 1 data bit voor het MPS-en (multi processor system).

onder andere hierdoor is het managen van die multiple processes slecht. De ultrasparc heeft een uitgebalanceerder hardwarematig multi processor structuur, en door de simpelheid van de instructies (reduced instruction set) is het makkelijker instructies te distribueren tussen processoren dan bij de zwaaar geSSI-de, MMX-de Cisc instructieset van een I86x apparaat.

maarre er zijn meerdere soorten TPC testen, met zware queries, snelle queries (b.v. een webserver met lichte backend als tweakers) etc. TPC is een onafhankelijk bedrijf welke deze uitvoerd en ze zijn op het org domein te vinden.
Lees het eens en er gaat een hoop gebrabbel je scherm over. wel leuk om te zien wie er waar bovenaan staat.

ook eng om te zien dat sql 2000 sneller is dan oracle btw.

[Verwijderd]

Wel een snel bakkie, jammer dat je er zo weinig aan hebt. De resultaten van de TPC-C test zeggen namelijk niets over het gebruik in de praktijk. Het enig wat de test naar voren brengt zijn verschillen in performance op basis van een vast gedefineerde situatie. Het leuke is nu dat databases en de data er in zich dynamisch gedragen. Dat de test met Sybase werd gedaan zegt in dat opzicht genoeg. Het is een van de minst gebruikte DBMS'en in een wereld waar alleen DB/2 en Oracle nog mee tellen.
Maar goed in speciale, bijna niet reeele omstandig heden is het ding snel. Maar alleen met een snelle db-server red je het niet. Een klein beetje congestie op je netwerk en de boel mietert in elkaar. Een slechte getunde tp-monitor doet de rest.

Men zou er goed aan doen om dit soort machines in een reeele situatie te testen, met een dynamische workload en ditto omgeving. Nu lijkt het een beetje op speedskien, leuk om te zien maar zwaar nutteloos.

[VROEM!]

Wat ook wel belangrijk is, is hoe veel power hij heeft per vierkante meter vloeroppervlak.
Ruimte is nogal duur namelijk in kantoren. En dan heb ik het niet over kostprijs van de grond, maar meer dat alle activiteiten in een gebouw moeten passen. Als je met dit ding ruimte kweekt voor nog een andere activiteit (bijvoorbeeld nog zo'n kast) kun je het prijsverschil met bijvoorbeeld drie of vier andere (die samen voor minder aankoop meer verzetten) terugverdienen. Ook is het waarschijnlijk makkelijker om 1 kast te onderhouden dan meer (duh)
Bovendien hebben de bedrijven die zo'n machine als dit kopen zoveel geld dat ze in de pauze hun reet af kunnen vegen met honderdjes, dus de breuk prestatie/prijs is hier iets minder van toepassing.

[Verwijderd]

Ook is het waarschijnlijk makkelijker om 1 kast te onderhouden dan meer (duh).

Ooit gehoord van de term "single point of faillure"? Het is dus de bedoeling dat je die zo weinig mogelijk hebt, liefts geen uiteraard.

Als een machine als deze uitvalt, heb je over het algemeen een gigantisch probleem, tenzij je er meerdere hebt. Overigens is het wel zo dat dat probleem bij een Sun Enterprise 10000 minder speelt vanwege de dynamic system domains -- deze hebben hun eigen kopie van het operating system en hardware resources kunnen real-time aangepast worden.

[zomertje]

'single point of failure': daar heb je inderdaad gelijk in, maar toch hoor je in de praktijk dat er bedrijven gaan centraliseren: en alles op 1 server gooien, Dan is er n grote snelle server nodig maar ook een snelle netwerkverbinding....

Ik me af wat daar de afwegingen voor zijn. Redenen die ik kan bedenken: Het kan de 'synchronisatie' van verschillende databases zijn(bij meerdere servers op verschillende lokaties) dat anders een probleem wordt. of misschien wel de kosten van meerdere lokaties(ruimte, hardware) en systeembeheerders. Of misschien nog andere argumenten?? Heeft iemand daar ervaringen mee??

[Verwijderd]

'single point of failure': daar heb je inderdaad gelijk in, maar toch hoor je in de praktijk dat er bedrijven gaan centraliseren: en alles op 1 server gooien.

Zoals zo'n $$(*)$# Network Appliance Filer die om de haverklap plat gaat. Hopla, ruim 2000 netwerk schijven pleite, en inloggen duurt 10 minuten. Ja, dat ken ik wel Leuk, zolang het kreng werkt. Alleen dat is dus niet altijd heel erg lang.

[EfBe]

1 centrale server kan helpen bij het beheren van knelpunten e.d. maar is ook een limitering van je groei. Een verzameling losse servers, gedistribueerd (wat kan, binnen een organisatie heb je lang niet altijd alles op 1 plek zitten), is makkelijk uitbreidbaar: zet er namelijk maar een doos naast

[picobyte]

VROEM 'k heb je gemod op "inzichtvol" maaruh die laatste regel klopt echt niet !
Als ze nl zoveel geld hebben zitten ze op een
vergulde plee met duizendjes als rectum reinigers

Whoops I mist something

[Abbadon]

Bij mij op het werk hebben we een redelijk aantal van deze dingen. De starfires kunnen snel zijn, maar ooohhhhhh wat gaat er vaak iets kapot; je wilt niet weten hoeveel borden er al vervangen zijn in betrekkelijk korte tijd. En deze ervaringen hoor ik ook bij andere firma's. Voor bepaalde nieuwe projecten is er dan ook maar voor een flink aantal E450's gekozen i.p.v. één 10000.

[Barend]

64 GB ram. Jezus...


Maarreh, "undisputed champion of the high-end UNIX® server realm"? Ik begreep dat UltraSPARC juist het zielige kindje is op de 64 bits markt, aangaande performance...

[Verwijderd]

Dat klopt. Eén Ultrasparc processor tegenover één concurrerende processor van bv. IBM of Compaq legt het af. Maar 64 processoren in één doos is gruwelijk veel, en de concurrende modellen van bv. IBM of Compaq hebben veel minder processoren, vandaar.

Aan de andere kant is het verschil niet zo groot als het artikel misscien doet voorkomen.

Edit: OS/390 machines worden geclassificeerd als mainframes. Zo'n Starfire draait gewoon Solaris.

[Verwijderd]

Nou ja, de OS/390 dozen van IBM kunnen 54 of 56 CPU's hebben. Da's niet veel minder.

En die 64 gieg RAM valt ook wel mee. Er zijn Storage systemen van EMC die al 64 gieg RAID-cache hebben.
Das wel effe wat anders dan 64MB RAM cache of je Smart Array 3200 controllertje

[Booster]

Welke 64 bit processor is er nog meer dan?

[biobak]

DEC (nu Compaq) Alpha bijvoorbeeld.

[Verwijderd]

Ja, dan kan iedereen zo'n systeem bouwen ( als je geld te veel hebt ) Gewoon wat meer processoren er in douwen en voila, je hebt de snelste single-system server. Dit kan IBM makelijk overtreffen als ze dat zouden willen

[Vuurvlieg]

hmm aangezien ik geen flauw idee heb hoe ik me vorige post moet veranderen doe ik het maar zo..

update:
4 dezelfde procs doen
20123.70
dus voor 64 zou dit worden
321979.20
het is echter maar 156,873.03
dus wat blijkt hier 50% van de tijd word maar gebruikt om daadwerkelijk transacties uit te voeren. (kan wat schelen omdat conf. misschien niet helemaal hetzelfde is maar toch scheelt nooit 100%) die andere 50% word dus waarschijnlijk voor een groot gedeelte gebruikt voor het multiprocessen op zich. om maar te laten zien dat het een extra cpuutje erin pluggen niet perse winst hoeft op te leveren...

[Vuurvlieg]

Zo simpel is het dus niet. Zulke machines moeten helemaal uitgebalanceerd worden bovendien kost het multiprocessen ook processorkracht. Op een gegeven moment kan het zijn dat je er een processor bij prikt en dat de prestaties dus gewoon achteruit gaan. We hebben het hier ook niet over een huis tuin en keuken computer. Dit is top technologie en als ibm een snellere zou kunnen maken hadden ze dat wel gedaan. (misschien niet kosteneffectief genoeg maar oke afgezien daarvan) Ik ben eigenlijk wel benieuwd hoeveel transacties 1 zo'n processor aankan, kun je vergelijken hoeveel het multiprocessor gedoe kost. maar es ff opzoeken.