I want to just give a small note – it was very good to meet a bunch of you at the conference back in April!

However, on to more serious business – I currently work for Electronic Arts, and at this point we are actually looking for Sr. MySQL DBA’s. So if you or someone you know is interested, feel free to email me directly at nwesterlund – at – ea.com . We will of course treat everything confidentially.

On a different note – the InnoDB plugin rocks in performance compared to the built-in version! I have seen test results (from my own test) ranging from 15% to 70% performance improvement! Good job there!

I want to take this time to thank everyone involved in MySQL and the surrounding community for their hard work, and express my wishes that you look forward to the future and what it might hold, I am sure it will be great.

I think that if done correctly, we as a community can benefit from these changes in the long run, so let’s look forward rather than backward.

On a sidenote, mysql.com is quite slow today, perhaps as a result of high load due to masses of people wanting to check out the news. However, sun.com has now been redirected to Oracle.com.

Turns out however that things such as the documentation is still missing, hopefully it will return soon. As an example for what I mean, take a look at the documentation and you will notice that it is all empty.

So, to everyone, a happy 2010 and best wishes to Oracle.

SQL Server
Over at Less Than Dot Ted Krueger brings up the question of the good, the bad and the ugly of database design where he says “In my career I have seen the ugly and then the really ugly but I found on this particular implementation it could get even uglier.”

Over at Carpe Datum the question is if wizards are evil or not where we are encouraged to fix the wizards.

Ever wondered about how much space is available in tempdb? The friendly people over at the Customer Advisory Team monitor free space in tempdb where they remind us that “Usually, unused transaction log space is reclaimed in tempdb is when the transaction log runs 70% full or if a user initiated CHECKPOINT command is run.”

Oracle
Now, let’s jump right ahead and take a look at what has been going on in the Oracle world this week. Starting off with Kerry Osborne’s Oracle Blog where we get a post on how to track changes to database parameters although it hits some limits with diskspace, as Kerry states “So that’s 174G for AWR data for 7 years with 3 nodes and one hour snapshots!”

Sticking to AWR, Doug’s Oracle Blog explains how you should never underestimate AWR, and what his favourite oracle blog this year was. This ties up nicely together with the previous post by Kerry.

Ever questioned just how good you are? How would you become an expert? Ever won DBA of the year awards? Husnu Sensoy has a post which he titled How to become an Oracle expert?, in which he explains the love behind his job and how to find – and become – a master yourself.

Let’s take a look at queries, specifically how to change an outerjoin query to one without as Gerwin explains in his blog Home of General Approach Performance Profiling

Over at DBA Kevlar Kellyn gives us a overview of the problems encountered by ORA-14097: column type of size mismatch. That’s one more bullet that the Kevlar managed to survive.

MySQL
Now let’s take a look at the MySQL world. There’s really been two big things going on this week, one concerning Oracle/Sun and the EC (Including how that affects MySQL and all forks) and the other being that MySQL 5.5 is now released. Let’s dive right into it, shall we?

First of all, there will be a MySQL Conference in April as usual, although not co-arranged with Sun.

Giuseppe provides a nice tutorial on getting started with MySQL 5.5 on his blog, The Data Charmer, basically it boils down to the fact that the new release model is now in full swing.

Now, since 5.5 was released Roland Bouman gives us a quick look at the SIGNAL syntax in his blogpost on how to validate mysql data entry. SIGNAL was introduced with the latest 5.5 milestone release (m2), and is an ANSI/ISO standard.

Innodb_io_capacity might be very tempting to tune, but take a look at what Jay says about in a post where he reveals his results of testing the parameter.

Over at the indian wind along the telegraph lines Kurt is trying to explain and set some facts straight on the response after Monty issued his call for action. Both of these posts has stirred up quite a lot of comments and emotions across the community.

Sheeri over at The Pythian Group has voiced her opinion on Oracle buying Sun. She also goes on saying “When others spread the fear, uncertainty and doubt that Oracle will somehow kill MySQL, I consider the source.”. And this is something that I personally agree with and share the same idea as Sheeri does.

That is all for this week folks, and I wish you a Merry Christmas in advance, and have a safe holiday!

I used sysbench for the tests, both fileio and oltp, although these results will be based on the fileio results. The setup with the disks in RAID10 (7 raid 1 sets, then striping over them) and later RAID50 (2 raid 5 sets with 7 disks each, then striping over that), the latter yielding better results.

Let’s take a look at 1,2,4,8,16 and 128 concurrent clients, with different IO schedulers, although using XFS.
The config for the raid controller was write-back, cached access, advanced readahead. 512MB battery backed cache on the controller.

Also, I tested both sequential reading (SEQRD in the graphs) and random read/write (RNDRW in the graphs)

Random Read-Write

Sequential Reads

So, in random access they were all quite bad, especially considering that I had expected better performance, but they were at least very close. However, sequential reading was a field where noop did a much better job, as all the others started dropping off after 128 clients, but I reached a peak around 384 concurrent clients with noop (and a throughput of ~518Mb/sec)

Now, in August Vadim had a post about ec2/ebs IO benchmarking, and the results that you will see below are better, but still not good enough in my mind, since I know that IO access on ec2/ebs is quite slow.

Anyway, let’s take a look at req/s and response time in ms, with 8 threads doing random read-write to keep the benchmark comparable with Vadim’s.

Req and ms

The latency here stayed pretty constant, and what is interesting is that the latency for each test was almost identical to each other as I scaled up the amount of threads as well.

One thing worth noting, was that with bonnie++, I would get similar results for one thread as I got with sysbench in the reading test, however, it turns out that linuxmesses around with device management even though it’s better off left to the controller in this case.

Take a look at this graph, which shows how much improvement you can get by using blockdev to change setra on linux even though that the raid controller should be responsible for that:

tweaking

In the next part, I will focus on finding the limits for each scheduler as well as see what is possible to get out of this array, but I am still waiting for additional hardware to arrive in order to do so.

As for which scheduler I recommend? For the workloads I tried with the oltp test, noop had the best results. These results will be published in the next part as well.