"Sun today announced new benchmark results involving the performance of the open source MySQL database running online transaction processing workload on 8-way Sun Fire V40z servers. The testing, which measured the performance of both read/write and read-only operations, showed that MySQL 5.0.18 running on Solaris 10 executed the same functions up to 64 percent faster in read/write mode and up to 91 percent faster in read-only mode than when it ran on the Red Hat Enterprise Linux 4 Advanced Server Edition OS." Take a look at the item below, though.
Post a Comment
Member since:
2005-09-21
Fans: 5
Member since:2006-03-14
Fans: 1
The news item on OSNews.com below this one.
http://osnews.com/comment.php?news_id=14710
Member since:
2006-05-02
Fans: 0
Member since:2005-07-06
Fans: 0
Member since:2005-07-21
Fans: 0
Member since:2005-09-16
Fans: 0
Member since:2006-02-20
Fans: 0
> and Tyan motherboards than Sun
I don't think its a Tyan mobo. The v40z is a Newisys 4300 with a different bezel and modified firmware on the system manager board (so far as I know, anyway).
It would be surprising if Sun and MySQL were not able to do this, geven that they both control their codebases, both have dedicated paid R&D, and both have something to gain from this.
Member since:2005-09-16
Fans: 0
Member since:2006-05-25
Fans: 0
Actually you're wrong. The Sun 40z and 20z are a rebranded system. The Tseriers are the first inhouse Sun Opteron boxes. You can buy the same v40z for Western Scientific. The systems are just a quad Opteron dual core boxes.
Personally I could not care about performance of toy DBs like MySQL. If they started comparing PostgreSQL or Oracle, I would be interested.
Member since:
2006-03-21
Fans: 0
Member since:2005-11-23
Fans: 4
Member since:2005-11-14
Fans: 2
Member since:2005-07-07
Fans: 2
Member since:2005-10-02
Fans: 21
Because most linux users aren't in it for the money, but for the pride. Therefore fakish tests are close to non-existent.
However, companies like Redhat, Novell and IBM are alike to Sun in this regard. I'd expect nothing else, considering their need for a steady income.
Member since:2005-07-08
Fans: 4
Well, I wouldn't be surprised that Solaris can beat Linux.
But for su much margin? Considering that mysql has always been biased and optimized toward Linux because it has been the main OS for mysql for a while and that we've seen mysql benchmarks where linux was beating solaris?
Not that it can't be possible (ZFS could be the reason why solaris is winning here) but it just look worth of taking time to analyze it carefully.
Member since:2005-07-07
Fans: 2
Member since:2005-10-08
Fans: 2
> Why does Sun even bother releasing benchmarks? We all know
> the results are biased. Personally I don't trust any study that's
> overseen by the same company
Haha... Except you Linux zealots wouldn't trust God himself if he told you that Solaris benchmarked faster than Linux because you are all so blinded by your platform loyalty.
Member since:
2005-07-06
Fans: 0
Member since:2005-09-16
Fans: 0
Member since:2005-07-08
Fans: 5
Unfortunately there is no information as to how the system was set up. It would have been nice to know more about how the operating systems were installed, filesystems were layed out and whether or not volume management was used.
Since a V40z can hold up to 6 drives, was the test conducted on a system with with 1 disk or more?
Member since:
2005-11-12
Fans: 3
Member since:2006-01-06
Fans: 7
Member since:2005-11-10
Fans: 14
Member since:2005-07-07
Fans: 2
Member since:
2006-01-11
Fans: 0
It's almost always possible to produce a benchmark showing that system A runs faster than system B, and to produce another benchmark showing that system B runs faster than system A. You just find the differences, and design the benchmark to exploit the differences.
Now, it is possible that Solaris engineers studied MySQL performance, identified bottlenecks, fixed a few, and the result is that for the moment Solaris runs MySQL faster. If so, it won't last long; Linux kernel developers will put the same tricks into Linux and everyone wins.
Member since:2005-07-08
Fans: 5
Member since:
2005-07-15
Fans: 0
Member since:2005-07-08
Fans: 4
It's always been superior to all free *nix variants when dealing with multiple processors and threaded apps
You know, Linux 2.6 is also know to be SMP and multithread friendly - if you follow the linux kernel mailing list you'll know that there's has been *lots* of work in making Linux work well in platforms even bigger than what Sun offers, like 512-CPU SGI's beasts.
Is not that Solaris can't win the test because it's not scalable. If you look at the numbers, Solaris beats Linux in those benchmarks even when running the *single* thread test. Hence, it's not so much about SMP scalability or multithreading, IMO. If it falls behind with 1 thread, is not surprising that it falls even more with 16. My bet is that it's ZFS which makes the difference. We know that ZFS rocks, but that doesn't makes the rest of the linux kernel any worse. It'd be interesting to see solaris-UFS and linux-XFS just for curiosity.
Member since:2006-05-25
Fans: 0
Member since:2006-01-03
Fans: 0
"You do know the difference Sun's SMP and that offered by SGI-- NUMA. Apple and Oranges. The 512 CPU are cluster on many small systems."
FYI, an SMP Opteron box is also NUMA, albeit on a smaller scale than an SGI Altix (Sun also sells NUMA boxes, AFAIK).
The 512-CPU Altix isn't a cluster, it runs a *single* Linux image (when you run "top" you see 512 CPUs - that's why recent versions of top default to showing only aggregate CPU statistics). It's made up of nodes, each with a couple of CPUs, but those nodes aren't independent, they make up a single, unified machine.
You do have Altix clusters (with "Columbia", at NASA's NAS, for instance), but those are clusters of several 256/512-CPU Altixes (which, like I said, are each a single machine).
Apples and Oranges? I don't think so.
Member since:2006-05-25
Fans: 0
"
The 512-CPU Altix isn't a cluster, it runs a *single* Linux image (when you run "top" you see 512 CPUs - that's why recent versions of top default to showing only aggregate CPU statistics). It's made up of nodes, each with a couple of CPUs, but those nodes aren't independent, they make up a single, unified machine. "
And the projection of a single contiguous memory structure between node is what NUMA provides. And your point is? The fact that the systems communicate on a high speed interconnect is different the the Sun Fire 6800 which I admin. In fact NUMA patches are required and possess different locking primative that the localized SMP model-- the big difference between NUMA and the large Sun Fire models is latency and thus the model is different.
Just try to run the Linux kernel on the 6800. You start seeing locking contentions after 12 CPUs and the scalability leveling off.
Member since:2006-02-10
Fans: 0
"My bet is that it's ZFS which makes the difference. We know that ZFS rocks, but that doesn't makes the rest of the linux kernel any worse. It'd be interesting to see solaris-UFS and linux-XFS just for curiosity."Not likely that ZFS is the difference. The performance was run on Solaris 10, which does not yet include ZFS. However, ZFS should first appear in Solaris 10 in the upcoming weeks in Solaris 10 Update 2 (s10u2).
Member since:2005-07-08
Fans: 4
Member since:
2006-03-06
Fans: 0
The article states that Sun worked with the MySQL team to optimize their systems for MySQL performance, so I'm not shocked that Solaris outran the RHES system. I am surprised, however, by *how large* the performance gap was. I'd like to see third-party benchmarks, of course, and it would also be nice if the MySQL guys would share what made the Solaris system so speedy with the rest of the *nix world. I wonder if their optimizations also had an effect on PostGreSQL performance as well?
Member since:
2006-05-25
Fans: 0
Member since:
2006-05-01
Fans: 0
Member since:
2006-05-01
Fans: 0
http://hup.hu/node/25441
(english article)
Member since:2005-07-08
Fans: 5
Which release of Solaris 10 was used because there are some issues using 3/05 with the T1000/T2000:
http://docs.sun.com/source/819-2544-15/index.html
Member since:
2005-08-08
Fans: 0
Member since:2005-07-08
Fans: 5
Member since:
2005-11-15
Fans: 0
Here's my take on the this benchmark:
ZFS was not used because ZFS it not available for Solaris 10, only Solaris 11.
The loads used were very large, and this was a massively parallel implementation. Sun used DTrace to optimize MySQL, saw a reasonable 10 - 15% performance increase (or something verabouts, I'm guessing here) over single server performance against Red Hat. They added more load and more servers in parallel to emphasize the performance benefit.
Yes, Solaris is faster than Red Hat under high loads. Yes, Solaris scales better to many processors. These claims have been made for some time, now here is the proof. Folks running single CPU servers under light loads may not see much performance difference between the two. But yes, Solaris scale up very, very well.
Sun is currently adding Solaris optimizations to PostGres as well. Looking forward to those numbers.
Member since:
2005-11-15
Fans: 0
I don't think we will see any benchmarks of Oracle on Solaris Vs Red Hat. Oracle forbids publishing bechmark numbers in their licensing.
I have only seen one 3rd party Oracle benchmark and this was done by PC Magazine some years ago. They decided to break the license agreement, and good for them.
Member since:
2005-11-15
Fans: 0
Member since:2006-05-25
Fans: 0
Member since:2006-02-02
Fans: 0
RedHat Enterprise 4 is now two years old in every sense of the word. Why not go back and compare against Solaris 9... FYI.
FYI, Solaris 10 is one and a half years old. RHEL 4 is at update 3 which includes patches and improvements. Both of them are current shipping version, it is perfectly fair.
Member since:
2006-01-06
Fans: 7
Anybody remember when Sun got caught when it claimed that its Java VM ran an order of magnitude faster than any of the other existing JVMs? It turned out that Sun's JVM contained logic that looked for a specific sequence of bytecodes matching the benchmark algorithm. When it detected the sequence, it ran an optimized piece of assembly code and, not surprisingly, none of the other JVMs were tuned in this way. However, Sun's JVM was pretty much identical (or worse) in performance when you ran specific cases that it wasn't tuned to handle.
In order to be credible, benchmarks need to be practical (ie. apply to scenarios performed in the real world), open to review, and orchestrated by an organization/individuals with no financial incentive in the outcome. Note: I'm not criticizing Sun's results here. It could very well be that its code is faster than competitors; however, one should take the results with a SERIOUS GRAIN OF SALT.
Member since:
2005-11-15
Fans: 0
>Ah because RedHat Enterprise 5 is not out. So we
>should hold back on one shipping version because the
>other vendor have chosen not to ship within the last
>2 years?????? Grasping for straws.
How about not testing against an OS that hasn't been updated within 2006?
And, uh... Solaris 10 was officially released in mid-2005, if memory serves.
Maybe Red Hat will see the value in updating their software to something more modern... and maybe I'll give a damn about them again if they do.
Member since:2006-05-25
Fans: 0
What you used RH E4? It has gone though 4 updates including kernel patches and changes. Yet that's not even the point.
If we were to use your "argument" We should not be testing Red Hat E4 against Windows Servre 2003 since RH4 was initially relased on 15 February 2005 while Windows 2003 Server was release almost 2 years ealier (April 2003).
"
And, uh... Solaris 10 was officially released in mid-2005, if memory serves. "-- Try Jan. 31, 2005
Looking at the release dates beteen RH E4 and Sol 10,
your release date argument is non-existent 1.5 months difference?
Your grasping.
Member since:
2005-08-28
Fans: 0
take solaris 10 running on a sparc (say a v240), and linux running on a dell (a poweredge, or even a higher end optiplex for instance). compile binutils on both using about the same version of gcc. time it.
in my case, about 4-5 hours on solaris. roughly 5 minutes on the dell...
I'm sorry, but several times where solaris is just getting through the configure script on something, I've seen linux done with the entire build of a collection when run in parallel next to each other.
it's not that solaris is such a bad system, but speed is not one of the traits it's renowned for...
Member since:2005-10-08
Fans: 2
Member since:2005-08-28
Fans: 0
Member since:2005-10-08
Fans: 2
> so, now you're claiming that solaris x86 (on a freaking low
> end workstation...)
I'm claiming that Solaris x86 on Opteron blows away Sparc, yes. The Sparc has fallen behind in recent times.
And dkeep in mind that if you were compiling on a dedicated server, that server wwas probably balencing a bunch of other tasks at the same time. hardly a fair test.
Member since:2005-07-07
Fans: 2
take solaris 10 running on a sparc (say a v240), and linux running on a dell (a poweredge, or even a higher end optiplex for instance). compile binutils on both using about the same version of gcc. time it.
in my case, about 4-5 hours on solaris. roughly 5 minutes on the dell...
That is rubbish. Are you cross compiling x86 binaries on SPARC? Compiling is the worst possible benchmark one can come up with ecspecially on two different ISAs.
Member since:2005-08-28
Fans: 0
um no, I'm compiling binutils for both platforms. it isn't limited to x86 in case you didn't know...
that's just one example however (though admittedly one of the worse). I've seen this disparity all over the place in preparing packages for both platforms. and why is compiling such a bad benchmark, it is a real world task that I have to do on both. one's slow, one isn't...
Member since:2006-02-11
Fans: 1
Member since:2006-04-09
Fans: 0
I'd agree that the time it takes to compile something is a horrible benchmark, especially with gcc. When I had an Alpha, it took a while to compile things. I read somewhere online that the register allocation phase of the compilation runs in O(n^2) with the number of registers to fill. With RISC processors having many times the number of registers as x86, it will take quite a bit longer for that step.
Maybe gcc uses an improved algorithm for amd64 and x86, since they're common, but for SPARC, it's possible the developers just try to generate code that is correct and have compile speed as a lesser concern. There's probably a dozen other places where the differences in architecture and gcc developer time makes a compiling benchmark suspect.
Member since:
2006-04-28
Fans: 1
I have nothing against Solaris, but it always seems to me a useless debate when it comes to compare performance, scalability and stability. We can all argue this and that, but in the end the facts are:
Among the top 500 supercomputers in the world, which cost millions of $$, which have the very best engineers to look after them, which run performance and stability critical tasks, Linux has about 78% of the market share. Solaris has 0.8%.
Do you really think it's just to save a few bucks in the OS? Oh wait, isn't Solaris even free now too?
Take a look at top500.org for the numbers.