Tuesday Aug 11, 2009

FrOSCon Logo

Do you plan to attend the Free and Open Source Conference (FrOSCon) in St. Augustin, Germany on August 22 & 23? Are you a fan of MySQL and would you like to share your knowledge about it with other users? Here is your chance!

Sun Microsystems is a Gold sponsor of FrOSCon this year and will also be present with a booth there on both days. In addition to demo stations about Open HA Cluster, OpenSolaris and NetBeans, Sun will also provide space for a MySQL info desk, which we would like to turn into a "Guru Bar", including members of the MySQL community.

The goal is to talk with existing and potential new MySQL users, share knowledge and expertise. We want to inform the visitors about what's new at MySQL and how they can get more information and help. If you have a solid MySQL background, are familiar with the various MySQL information resources (e.g. the DevZone, Forge, Forums, Mailing Lists, Planet MySQL) and enjoy talking to other users, we would like to hear from you! If you're interested in participating at the Guru Bar, please contact us at mysql-community AT sun DOT com for details. Thank you!

Wednesday Mar 18, 2009

If you liked the article on QA before releasing, you may want to mark your calendars for this session at the MySQL Users Conference and Expo 2009, where Omer BarNir and Trim Pershad will tell everything about Software Quality and Testing in MySQL.

Trim and Omer are veteran QA engineers, whose main goal is to improve the quality of MySQL products. Their session will tell you how the QA process evolved and what is going on right now.

MySQL Conference & Expo 2009

Thursday Feb 12, 2009

FOSDEM, the Free and Open Source Software Developers' European Meeting

Now that FOSDEM 2009 in Brussels, Belgium is over, it's about time for a conclusion/summary. I've been to FOSDEM for about five times as both an attendee and speaker, but this year I was much more involved. On Saturday, I gave a lightning talk about "Why you should use Bazaar for maintaining your OSS project". On Sunday, I gave a talk about "MySQL High Availability Solutions" in the main conference track. Both went fairly well and there was good feedback from audience. I've uploaded the slides for both talks to the FOSDEM 2009 page on the MySQL Forge Wiki, video recordings of the sessions should be available on the FOSDEM Video Recordings page soon.

We had a project stand that we shared with the OpenSolaris project, and it was particularly nice to finally meet Roman Strobl in person - he is a former NetBeans evangelist, now OpenSolaris evangelist who blogs on The Observatory. We had quite a lot of visitors stopping by at the desk. I would like to thank Walter Heck and Santo Leto in particular for their outstanding support with manning the desk!

On Sunday, we had a MySQL Developer Room with a full schedule of talks. We had to make some last minute changes to the schedule, one speaker had to cancel his talk on short notice due to a family emergency and we decided to change to topic of Kaj's talk into an interactive Q&A session to address the recent developments that happened that week. The room was usually packed for every session (~70 people), and it seems like both the attendees and speakers had a great time. The slides are now available from the MySQL Forge Wiki.

On this page, you will also find links to related articles and blog postings about the MySQL activities as well as links to pictures - feel free to add other pointers that you are aware of! I would like to thank all speakers for their excellent contributions, especially our volunteers from the MySQL Community: Roland Bouman, Kris Buytaert, Vladimir Kolesnikov and Jurriaan Persyn. Keep up the great work!

In summary, I think the MySQL DevRoom and project desk were a great success and we should have one next year, too (and maybe on other conferences as well). However, there are several things that could be improved for next year. My lessons learned:

  • Try to avoid last-minute changes to the schedule after the conference brochures have been printed
  • Align the session times with the main conference sessions, to allow easier transition and avoid overlap
  • Appoint a moderator that keeps track of the DevRoom schedule and takes care of the speakers and Q&A parts
  • Hire/appoint someone to record the sessions on video
  • Don't schedule yourself for booth duty, if you are also a main track speaker and DevRoom organizer
  • Take some time to properly introduce and brief all volunteers about activities and people involved
  • Make sure that volunteers that offered to help out with booth duty actually show up and are available, keep a printed copy of the booth schedule on the table
  • Provide free drinks and snacks for the people on booth duty
  • Set up a proper demo system for showcasing applications in advance, don't rely on Internet connectivity on site
  • Have more MySQL-branded merchandise/schwag to hand out
  • Have more info material/leaflets about the relevant offerings available, in the appropriate language
What else do you think can be made better next time? Please let me know. Thanks!

Tuesday Feb 03, 2009

MySQL & Open HA Cluster
A while ago we published an interview with Detlef Ulherr and Thorsten Früauf about Solaris Cluster / OpenHA Cluster on the MySQL Developer Zone.

We received a number of followup questions from our readers, requesting more technical background information. For example, Mark Callaghan was wondering about the following:

  • How is failure detection done?
  • How is promotion of a slave to the master done after failure detection?
  • How are other slaves failed to the new master?

I asked Detlef to elaborate some more on the technical details of this solution. Here's his very exhaustive reply, thank you very much, Detlef!

I would also like to point out that he'll be speaking about Solutions for High Availability and Disaster Recovery with MySQL at this year's MySQL Conference & Expo in Santa Clara, which will take place on April 20-23, 2009.

But now without further ado, here are Detlef's answers:

[Read More]

Thursday Dec 11, 2008

We’re very excited to see MySQL 5.1.30 make it to GA status and are very proud of the work that the MySQL engineering team has done to get MySQL 5.1 out of the door.

Maybe you’ve seen some claims by others in the MySQL community that MySQL 5.1 runs slower than MySQL 5.0. Maybe you’ve also seen some claims by others in the MySQL community that MySQL 5.1 runs faster than MySQL 5.0.

Guess what? They’re both right.

With database or any other hardware/software performance tests, you’re always going to see different results because there are *so* many variables that go into the equation.

That being the case, I thought I’d share a little of what we in the MySQL QA group have seen on the 5.1 vs. 5.0 front. Part of our job in MySQL QA is to routinely test each MySQL build and compare it to prior versions before release, to see if any performance regressions have occurred and I would like to share the most recent results with you.

We did multiple tests with dbt2 benchmark on 5.1.30 GA and 5.0.72 and the charts below represent the outcomes with different settings for innodb_thread_concurrency parameter. Finding the optimal setting for this parameter largely depends on hardware, OS and workload.

In our case we ran CPU bound scenario (dbt2 benchmark with 10 warehouses that fits into buffer pool) and 
varying innodb_thread_concurrency parameter by setting it to: 0, 8, 16, 1000.

Chart 1.Results per threads for the 5.0.72 and 5.1.30
innodb-thread-concurrency=1000

Chart 2 Results per threads for the 5.0.72 and 5.1.30 innodb-thread-concurrency=8

Chart 3.Results per threads for the 5.0.72 and 5.1.30 innodb-thread-concurrency=16

Chart 4. results per threads for the 5.0.72 and 5.1.30 innodb-thread-concurrency=0

 

As seen above, with  innodb_thread_concurrency of 8,16 and 1000, MySQL 5.1  out performs 
MySQL 5.0, by 21-41% depending upon the threads we use. This also demonstrates improvements 
in scalability in 5.1
 
The best throughput for this combination of hardware, OS and workload for both 5.0 and 5.1 servers were 
achieved with innodb_thread_concurrency=0. There is very little difference between 5.0 and 5.1 in this test
(5.0 has very slight edge over 5.1) 

Additionally we also run other tests (sysbench) prior to every release. For 5.1 GA release, we found that in some cases 5.1 performed better, while in some others there was a dead heat between 5.0 and 5.1.In few others we found 5.0 winning over 5.1

So what does it mean?

To summarize, the performance numbers will always vary when running benchmark tests based on variety of factors, so the prudent thing for you to do is download the latest MySQL 5.1 for your platform, put it through the wringer in your environment, and go with what works best for you

Test Details:

Hardware: 
  - dl360-g5
  - Intel x86_64 (Dual Quad-Core Xeon 5345)
  - RAM 16GB
  - RAID: Smart Array P400i/ 1+0, CACHE 256MB, 4 SAS Disks 10000RPM
 
OS:  
  - SLES 10
  - kernel - 2.6.16
  - fs - ext3

dbt2 test details:
  - version of dbt2 test - 0.37
  - scale factor - 10 warehouses
  - zero "think time" (-z)

How we run the test:
 - each run performed 3 times so represented results are average values 
 - test sequence for each run looks as following:
   - copying data files prepared in advance
   - start server
   - start test
   - test for 15 mins
   - stop test
   - stop server
 
The following packages were used:
   - 5.0.72 x86_64-glibc32
   - 5.1.30 x86_64-glibc32

The following InnoDB options were used:
   --innodb_status_file=0
   --innodb_data_file_path=ibdata1:100M:autoextend
   --innodb_buffer_pool_size=2G
   --innodb_additional_mem_pool_size=20M
   --innodb_log_file_size=650M
   --innodb_log_files_in_group=2
   --innodb_log_buffer_size=16M
   --innodb_support_xa=0
   --innodb_doublewrite=0
   --innodb_thread_concurrency=<0,8,16,1000>
   --innodb_flush_log_at_trx_commit=1
   --innodb_flush_method=O_DIRECT

About the author

Trim Pershad manages the MySQL database System QA team, since joining the company over a year ago. He also has extensive prior experience in testing databases Part of his team's responsibility is to test the MySQL database and compare performance results with earlier releases to identify any performance regressions.

This blog copyright 2009 by Lenz Grimmer