Feeds

back to article Oracle shows off M9000s for data warehousing

Oracle may not be as chatty as the formerly independent Sun Microsystems, but it sure is more keen on using benchmark tests to help make the case for the products it sells. And so Oracle has whipped out yet another benchmark, in this case using the TPC-H data warehousing test, to show that the top-end Sparc Enterprise M9000 …

COMMENTS

This topic is closed for new posts.

This post has been deleted by its author

Anonymous Coward

M9K vs E25K

Having had personal experience of both M9Ks and E25Ks, the latter is heavily hamstrung by relatively slow interconnects and what was a very old fashioned I/O system based on PCI (the fastest I/O buses on an E25K were 66Mhz 64bit which means that it's not really up to running a dual port 4Gbps FC card (especially when you know that FC is full duplex). Nor, of course, is it up to 10Gbps Ethernet standard. There ae ways round it - more cards in I/O system boards, network aggregation and SAN I/O balancing, but it looks increasing old hat and expensive compared to a modern x86 server, let alone direct competitors.

In comparison, the M9K has got PCIe and is a vastly more capable I/O box and the interconnects are a lot better (and, the RAS features are better too).

SMT is something of a mixed blessing. The various very similar versions of this (Hypertheading on x86, the equivalent on Itanium and Power) are fine where you have lots of largely independent threads working on large data sets with enough processor cache misses to make it worthwhile. However, in the case of a large, unified database like Oracle, there are large numbers of points where individual threads need exclusive control of a resource. The path time through those sections has to be kept as short as possible on SMPs or the DB will waste much of he CPU away on spin locks. If you enable SMT on a DB like this, then the threads on the same core will contend when they are both busy and if you believe the figures, you get, at best, 20% more throughput with SMT which means that two threads despatched on the same core will each only run at about 60% of the speed (on average). Path lengths go up, contention increases, cpu is wasted. In general, single DB benchmarks work better with fewer, faster cores. That's not to say that more cores can't be used - if your application uses a lots of procedural code running within the DB then this isn't necessarily true, but for a benchmark like this, it probably is.

So, like all these things, it's the application that matters. As it is, the M9K is a very decent bit of tin and much, much better than anything Sun had to offer in that space.

0
0
Silver badge
Unhappy

Ugg.

Didn't need that on a Friday afternoon.

My.

Brain.

Hurts.

0
0
Silver badge

No shock on the lack of SMT

The author wrote:

"For some reason, Oracle turned off SMT during the test and only loaded up half the cores in the box. That would seem to imply that something - perhaps the Oracle 11g R2 Enterprise Edition database used in the TPC-H test - can't scale well beyond 128 threads. "

I don't know if its a 128 thread limit, but most databases tend to perform better when SMT is off.

As to your comment of 'loading up half the cores' I'm not sure if you mean because SMT is off or they only used half of the physical cores present.

0
0
Silver badge
FAIL

Big Blue Blinkers?

(Sigh) I know that TPM seems to think that his job description is IBM promo and nothing else, but he missed the biggest message in the whole mix when he rushed off to dig out his IBM Power comparison. This is good news for the many Sunshiners still out there.

Running these benchmarks is not a cheap endeavour, so we have Snoreacle paying out for resources, kit and publicity, and Larry doesn't spend money without a reason. This is Larry saying to his installed Slowaris base "Hey, don't leave my table just yet, I'll keep serving pie as long as you want to buy it!" The fact they did the bench on M-series - Slowaris-only - shows he hasn't quite given up on traditional SPARC-Slowaris. The fact it's a big instance Oracle benchmark will also have appealled to Larry - he doesn't do small! The fact that it's another completely irrellevant benchmark - I mean, whom has that storage setup used? - is also very much Larry The Showman's style.

So, before TPM rushed for the IBM promo gear, he should have thought what this meant to us customers that still have SPARC-Slowaris instances in their business (yeah, I haven't quite managed to get rid of them all yet). Slowaris users won't care that the Power kit might manage to be a few percent faster in an equally unrealistic lab setup, they will see Larry saying there are still options for SPARC-Slowaris, and it will be much cheaper and easier (and not mean any re-skilling is required) for them to buy new M-series and carry on with their current app stack, rather than buy Power, Itanium, Xeon or Opteron replacements. This was what Larry needed to be saying when the Sunset deal went through, so he may have already lost some of those Slowaris shops. But the economic downturn probably put many migration plans on hold, so he may now have a second chance at keeping the Slowaris business alive if he can convince them he means to keep the SPARC-Slowaris option alive.

/Shaking head and laughing.

0
1
Anonymous Coward

IQ

"Nothing against Sybase, but it is only used in niche areas, like financial services." Not really true of IQ which seems to be becoming more and more popular, even with sites which use Oracle for OLTP.

0
0

This post has been deleted by its author

TPC-H and Compression?

It is interesting to note that booth the Oracle and IBM benchmarks did not use database compression. One would assume that for a DW type benchmark (TPC-H) database compression will help reduce the DB size and improve effective data scan rates. I can understand that Hybrid Columnar Compression (HCC) with potential of 10X compression cannot be used in non-clustered benchmarks as it is Exadata V2 only feature. Not sure how compression performs on the Sybase IQ side for such range of databases.

Thanks

0
0

Joerg

Interesting, thanks for sorting some details out! :o)

0
0

This post has been deleted by a moderator

Thumb Up

expect more benchmarks after further solaris optimizations

http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6778289

0
0
This topic is closed for new posts.