Slashdot Mirror
First Industry-Standard Benchmark On 64-bit Linux
Haider writes "IBM has published two TPC-H benchmarks at the 100GB and 300GB scale factors (meaning the raw data in the database). The results are published at www.tpc.org/tpch/results/tpch_perf_results. The two results were published with exactly the same hardware and show scalability of the solution as more data is put on it. The system was a cluster of 8 2-way nodes running 2GHz AMD Opteron cpus with 6 GB of memory on each node. The OS was SLES 8 for AMD, and the database was 64-bit DB2 for Linux. The details of this solution are described in an article at infoworld.com."
What's the performance like with Redhat Server and MySQL?
...and only 2GB of RAM. (Or can RedHat support 3?)
Informatus Technologicus
http://news.com.com/2100-1006_3-5057691.html?tag=f d_top
The headline here is absurdly wrong. These benchmarks are most certainly NOT the first to be performed on 64-bit Linux. Just to name one example, SGI published SPECfp_rate, STREAM, and Linpack benchmarks on their Itanium 2 systems months and months ago.
This is a benchmark. It is not the first, nor is it the most important.
And the numbers are staggering. ^_^ How many CPUs (total) are in each cluster ranked?
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
RH works great with 4 GB RAM, so I'm really hoping your comment was tongue-in-cheek. :)
What stands out for me is that the cheapest platform from these results, across 100GB, 300GB, and 1000GB, is actually from Sun - look at the Price/QphH figures. So much for all the hype about Linux solutions being cheaper... although it does show that Linux solutions can be scaled very high when used in clusters.
You tell me how well MySQL handles the below in comparison to other DBs.
TPC-H is also about 25% writes / 75% reads on tables with billions of rows. I do hope you're not using a table lock for readers / writers. Frankly, I hope you're using some form of MVCC so writers do NOT block readers.
It also uses large parts of advanced SQL92 and SQL99 features (Subselects in the from clause being very common).
Common tricks to speed things up is to use prepared statements, compiled procedures, can be much faster than without (less network overhead, parsing, or plan generation).
Queries use for TPC-H like benchmark by OSDL. It is a pre-beta, but shows the types of queries you are dealing with.
Rod Taylor
A cluster with 16 2GHz Opteron processors, running SuSE Enterprise Linux and DB2 beat a Hpaq system with 64 900MHz PIII Xeon processors running Win2k Advanced Server and DB2. I'd say that's cause for celebration at least.
Gabriel Ricard
If you'll notice, the colum where it has total QphH figures is the big telling factor here. Look down at the 10,000gb range, for example. When you scale up the total QphH, your cost per QphH also rises (kinda like how a P4 costs more per Mhz at its highest stepping as compared to the next highest stepping). The Solaris solution that is 40$/QphH is also 1/12th as powerful overall.
A fairer comparison would be to something with a similar overall power. HP's offering with only 100 less QphH than IBM's offering costs 203$ QphH vs. the 65$ US of the IBM version.
I think it's really amazing that an install whose raw power is so much higher than anything else in the class is still as affordable as IBM's nearest Windows solution, which gives you half the power for about the same price per QphH.
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
Linux is dying! Thanks SCO!
It certainly does seem that the Linux/DB2 combination works pretty well for high throughput, relatively small database systems. I am surprised how economical such a powerful system is.
Somewhat of topic, but I notice once again that the Japanese, in the form of NCR, have easily the most scalable systems at the high end. The evidence for this is everywhere, but I doubt many outside Japan realise it.