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!
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.
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!
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!
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 chartsbelow 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
- 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
About this weblog
MySQL Community Blog.
Guest posts, technology, and friendship for MySQL
What's this?
Feeds let you keep up to date with the latest information on a blog or website.
Right-click on a feed link and copy the link's URL, then paste it into your feed reader.
Some browsers also allow you to click a feed link and subscribe directly.