c0t0d0s0.org

This must be something like their inner October Revolution Parade or 4th of July fireworks for our beloved competitor. Their FUD seems to be effective. Reuters writes in "Sun Micro losing $100 million a month, Ellison says":

Oracle Corp (ORCL.O) Chief Executive Larry Ellison said Sun Microsystems Inc (JAVA.O) is losing about $100 million a month as European regulators delay approving his company's $7 billion purchase of the struggling hardware maker.

I'm still asking myself, who told the EC this Mysql bullshit. Sorry colleagues at Mysql, but Mysql will be never in the same market like the RDBMS market. And it shouldn't be in that market. For some people it's already too far in this market, today. That's one of the reasons for Drizzle. I think the markets are pretty much complementary.

Additionally: The code is open source. Whenever Oracle would decide to stop developing Mysql, there would be other companies starting development instead of Oracle. When Oracle Support of Mysql is too expensive, there will be other companies offering cheaper support. That's is the only advantage of open-source in my opinion for 95% of all users, because most people never see the source even at Makefile distance, as they just install a package.

Charles Suresh published some interesting findings in "Improving MySQL/Innodb/ZFS read-only performance by 5x using SSDs for L2ARC". In this case he tried a workload with low locality, where just 5% of the blocks where reread again (thus showing cache-busting behaviour). Instead of a pretty minimal performance improvement (as suggested by theory) Charles got an performance improvement by factor 5.

At end this workload was one of this corner cases defying standard tuning knowledge. Normally you would match database block size and storage block size to get optimal performance. But this would hurt performance in this special case because the prefetching of ZFS wouldn't help as less data is cached. Cached? Yes, cached! ZFS doesn't cache just the mysql block you've used in this situation. That wouldn't be sensible. When you already have the data, you can cache them. Let's assume you have a 128 KByte blocksize and the 16 KByte blocksize. So you've read 8 blocks mysql-blocks with one ZFS block. Even in a cache defying workload there is a certain propability that even when you don't use block x again, you will use block x+1 to x+7 while it's in the cache. And this prefetch by mismatching blocksizes is largely responsible for the performance boost, where you didn't expected one. But: Without the mismatching blocksize you wouldn't have read this data into the cache, thus the system would have to go to the disk, thus resulting in lower performance.

Obviously the same effect is true for the normal ARC but as the ARC is normally much smaller than the L2ARC you have a high propability that the prefetched but unused mysql blocks are already evicted from the cache, when you need them. The larger cache provided the SSD reduces the propability that the data gets evicted from (L2)ARC before your workload uses the prefetched blocks.

Roger Bitar did some really interesting benchmarks with mysql on SSD. In his benchmarks he artificially constrained the availability of memory for the mysql buffers (aka cache):

We choose to test MySQL, the open source database (DB), using a simple MySQL benchmark called Sysbench. We populated the Sysbench table with 112 Million rows (around 26GB size) that fit on 1 SSD drive . We executed read-only queries while varying the buffer size. We mounted the file system in DIRECTIO mode to disable file system caching. We perfrormed the tests with regular HDDs and repeated them with SSDs.

There results were somewhat astounding. Of course a fully memory saturated database is the fastest way to implement a database (buffer cache at 24 GB). But with a database on SSD Roger was able to yield 96 percent of the performance of the in-memory database even with heavily constrained RAM space (buffer cache limited to 8 GB). The latency at memory constrained situation is vastly better with SSD than with rotating rust.

This leads me to an interesting conclusion: When you just compare the power consumption of SSD and hard disks (aka rotating rust), you forget a part of the equation. Let´s assume a FB DIMM takes 10 watts (it´s a little bit more, but 10 is easier for calculating). In the benchmark you were able to have almost the same performance with SSD (2 watts) at 8 GB as at 24 GB. Let´s assume 4 GB DIMMS. You would save 18 Watts (10*2-2) by using the SSD. Okay 18 watts isn´t a big deal, but now think about a 240 GB database.

You can design your database server in quite a different manner, when you take SSD into your considerations.

The usage of SSDs has an really big impact on the performance of mysl. Kazuho Oku wrote about his experiences with the Intel X25-M ssd in "Benchmarking SSD for MySQL". Looks really promising.

Don gave an update to his article about mysql on Opensolaris. Now he published an update to his article with ZFS & MySQL/InnoDB Compression Update:

Conclusion? Unless you care a great deal about eking out every last byte (using a RAM disk, for example), LZJB seems like a much saner compression choice. Performance seem to improve, rather than degrade, and it doesn’t hog your CPU. I’m switching my ZFS volume to LZJB right now (on-the-fly changes - woo!) and will copy all my data so it gets the new compression settings. I’ll sacrifice some bytes, but that’s ok - performance is king.

Don MacAskill (the CEO of SmugMug - yeah CEO and geekdom isn´t mutually exclusive) did an interesting experiment - he used an Opensolaris system for one of his database replicas. And his experiences were really positive (besides of the usual pet peeve we already working on ):

I’m a Linux geek, have been since 1993 (Slackware!). All of SmugMug’s datacenters (and our EC2 images) are built on Linux. But the current state of filesystems on Linux is awful, and it’s been awful for at least 8 years. As a result, we’ve put our first OpenSolaris box into production at SmugMug and I’ve been pleasantly surprised with the performance

The configuration has a really interesting speciality. He used compression.

Lo and behold, it worked! We’re getting a 2.12X compression ratio on our DB, and performance is keeping up just fine. I ran some quick performance tests on large linear reads/writes and we were measuring 45.6MB/s sustained uncompression and 39MB/s sustained compression on a single-threaded app on an Opteron CPU.

I planed to write an article about this "Sun will close the source of Mysql" nonsense. Alec Muffet summarizes the real story of this Enterprise/Community Edition discussion on his blog in Whats the SQL? by linking to an authoritative source: A Slashdot article written by Marten Mickos, the former CEO of Mysql AB .... wait ... a CEO writing at Slashdot ????

I found two really interesting interesting presentation. At first Brent Paulson wrote an really interesting presentation about practical Opensolaris Security. It´s a good overview about the possibilities of Solaris to increase the level of security at your installation. Ben Rockwood of cuddletech.com wrote an good preso about the usage of dtrace in conjunction with mysql.

Kishore Singh Thakur published with "MySQL InnoDB Performance Tuning for the Solaris 10 OS" an excellent article about tuning mysql and Solaris. A must-read.

Wired reports about the Mysql AB in Sun Pays Up the Wazoo -- $1 Billion -- for MySQL. The article itself is not so interesting, it´s one of this terms and conditions articles, which were legion in the last few days. Nevertheless there is a comment in the article , which explains my antipathy in regard of the most surplus profession - analysts

"Less than 1 percent of MySQL users pay," wrote Global Equities Research analyst Trip Chowdhry. "Users are in the habit of getting free stuff and it's impossible to break the habit. . . We don't see Sun (being) able to monetize it."

They don´t see an opportunity even a blind man at midnight would recognize. At first: The tens of thousands of users, who run their blog on a mysql database on their debian server are commercially uninteresting, there are more interesting to build an opportunity. But there are users, who run their websites or their applications on mysql and need a supported database, but don´t want to spend a fortune for oracle. And these people want to pay. And at the size of the Mysql community 1 percent of users are a large group of customers.. It´s simple, these "research analys" simply don´t understand the model of open source, i doubt they understand the IT business as whole.

Even when we are note able to monetize the Mysql at large, but with Mysql we have a powerful enabler to talk with companies about our products, about our servers. We get important even for a pure Linux on HP, Dell and IBM shop, as we own the M in LAMP now. And this is an important point to monetize on the 1bn $.

Paul Murphy comments in Fun with Sun in Forbes the latest articles at Forbes.com about the Mysql AB deal. This article contained so much errors, that i´m decided i won´t link it. But Paul summarizes it quite good:

In summary pretty much everything Greenberg says here is filtered through a soul deep mask of ignorance - but our problem is that a lot of our bosses are in his audience - and I don’t expect Forbes to be publishing corrections any time soon.

Jonathan answers some questions about the deal in his newest blog entry: in a vortex

The second-last paragraph matches my experiences as well:

And having listened to about 10 customers face to face over the past couple days, I've heard only one comment, made consistently - "Congratulations, this is absolutely fantastic news for all of us!"

I´ve read many articles and comments in varius internet publications and communities which speculated about the future of Mysql now Mysql AB will be acquired by Sun. There are some concerns about "Will Mysql be an Solaris-only thing", what will be the focus of the further mysql development. I thought a little bit about this fears. At first ... this thoughts are my own opinion. I don´t now much about this deal. The deal surprised me as well as most people out there. I don´t think that i have much more informations like the ones circulating in the net. Okay ... let´s start ....

I don´t know, what Mr. Dvorak has done in the past to justifiy, that such underinformed and underthought articles like this are still published by someone. This is the same guy, who tried to told us that the iPhone battery has only a reach of 40 minutes and years before he wrote, that the computer mouse will be a gadget nobody will ever use, that Apple will switch to Windows ... and other pearls of computer journalism.

Jason from Digitar describes in his blog how he is backing up his mysql databases with ZFS. He published his backup script was well.