It is not a secret that we’ve been kicking the tires and playing with JIRA for project management. After using it since the beginning of the year most of us like the feel of it and we’ve decided that it makes sense to start using it more.

As you know, the MariaDB project has many fragmented resources. We report bugs in Launchpad. We store our plans in worklog. We’ve never used the Launchpad Blueprint feature for this very reason. We don’t use Launchpad Answers because we have the Knowledgebase.

With this move to hosted JIRA (yes, this is an important link: http://mariadb.org/jira) we can report bugs, have future plans, and also give users a roadmap which is pretty cool. One nifty feature is that in the past two releases, we had a roadmap and we didn’t slip in terms of a schedule. We had on time releases and that’s awesome!

So what does this mean for you? To report bugs, you will now do so on JIRA. To make feature requests and talk about our future plans, you will also now use JIRA.

We plan to deprecate Worklog and Launchpad bugs by 30 June 2012. Launchpad will however continue to host the source code for MariaDB.

What will happen to bugs already reported on Launchpad? We have migration scripts ready for this and when we press the button bug reports will nicely migrate over to JIRA. After that is done we’ll place a notification on the MariaDB bugs page in Launchpad about reporting new bugs in JIRA.

What will happen to feature requests and ideas already in worklog? Worklog will be put into a read-only mode and there will be notifications about the move to JIRA. Whenever needed we’ll copy & paste worklog items into JIRA.

What does it mean to the openness of the MariaDB project? It’s not affected at all. The MariaDB project will remain an open community friendly project and as a bonus it will be easier to follow what is going on in the project since you don’t have to jump between several tools to get the complete picture.

The consolidation to JIRA provides the means to report and track project status easier than before, which allows the MariaDB team, community members and other to better coordinate and prioritize work.

As a side note, JIRA (and other software by Atlassian) has sometimes been criticized in the open source world because of its commercial nature and many are unaware of the fact that Atlassian do offer a free Open Source Project License to open source projects, which is what is being used with MariaDB.

As another side note, I’m not going to dive into comparing features in e.g. Launchpad with features in JIRA. I do know it would be possible to use blueprints for feature specifications etc. in Launchpad. The most important aspect in my mind is that you pick a tool that you like the feel of, has the features you need and tightens collaboration between developers, project managers, community members and other persons involved in the project.

In short, this is all about three project tools becoming one.

Over the past few days extensive conversations around a new security vulnerability in MariaDB and MySQL have taken place.

It all started as a chain reaction when Monty Program publicly disclosed information about the flaw they had found and about how to make sure your MariaDB and MySQL installations can be fixed. The initial information got assigned the security vulnerabitlity identifier CVE-2012-2122 and the contents can be seen e.g. here http://seclists.org/oss-sec/2012/q2/493.

The bug was found two months ago on April 4th.

Before disclosing the information publicly, given the seriousness of this bug and considering the millions of MySQL and MariaDB installations deployed worldwide, Monty Program informed the biggest distributors of MySQL and MariaDB as a precaution.

On April 6th, Monty Program informed Oracle about it in bug report http://bugs.mysql.com/bug.php?id=64884 and provided a suggested fix.

The other big distributors of MySQL and MariaDB are the major Linux distributions that were alerted also in April and provided with a fix for old (unsupported by Oracle) MySQL versions. This gave Oracle and the Linux distributions some lead time to check if their MySQL and/or MariaDB builds were vulnerable and apply the provided fix if needed.

Whether your MySQL or MariaDB installation is vulnerable depends on where and how the binaries you use were built.

Official binaries of MariaDB, provided by Monty Program, MySQL binaries provided by Oracle and – in the case you use Percona’s provided binaries of their server – have all been tested. All these vendors have confirmed that the vulnerability isn’t present in their binaries and that it actually has never been present due to the way that the binaries are built.

All binaries listed on the SkySQL website are either official Oracle or official MariaDB binaries mirrored from dev.mysql.com/downloads and downloads.mariadb.org.

If you built your binaries yourself, you (or your database administrator) can easily test if your installation is vulnerable or not by following the instructions found e.g. here http://ronaldbradford.com/blog/repost-a-tragically-comedic-security-flaw-in-mysql-2012-06-11/.

In the case that you build or have built your own binaries another good piece of information is that the fix (getting rid of the problem independently of how you build) was first released in MariaDB in version 5.5.23 on April 10. Oracle followed by having the fix in MySQL 5.5.24 on May 7.

Most of us, MariaDB and MySQL users, do not have a need to build binaries on our own, i.e. we are on a platform that the official MariaDB and MySQL binaries are provided for and we do not have our own patches that would need to be applied before producing our own binaries.

For most of us it’s therefore recommended to get the binaries from the official channels, such as through the Linux distribution you use via the distribution’s repository or through the official download channel of the database, which in the case of MariaDB is http://downloads.mariadb.org.

Also, if you want to make sure that you’re on the latest version of MariaDB and you’re running on CentOS, Fedora, Debian, Red Hat or Ubuntu you should consider adding MariaDB’s official repository, http://downloads.mariadb.org/mariadb/repositories/.

MariaDB and/or MySQL packagers (such as Linux distributions) should make sure they sign up for the MariaDB mailing list intended for packagers at https://lists.askmonty.org/cgi-bin/mailman/listinfo/packagers to receive important notifications including early disclosure of security vulnerabilities, like this one.

We haven’t posted any Windows benchmarks for a while, and MariaDB for Windows contains some specific improvements which might not be widely know since we haven’t talked much about them yet. This post is an attempt to fix that. We’ll also share current MySQL 5.5 numbers.

My setup is an 8 core 2 socket server (yes, a little bit dated for today, but it is the best machine I have at my disposal), 10K SAS disks with RAID1. I ran sysbench 0.4 single table / 1,000,000 records. I ran the benchmark over a network, with the number of concurrent clients ranging from 4 to 4096.

Here is what OLTP-readonly throughput looks like:

  • For most of the tests, MariaDB’s throughput is approx 10% higher than MySQL’s
  • For 4096 concurrent clients, MariaDB’s throughput is better than MySQL 5.5 by 476% (2382 vs 413 TPS).

Many people rightfully remark that throughput does not necessarily represent performance as a whole, and that in OLTP benchmarks, fairness also matters. It actually often matters more than throughput. I agree, so below are the results for 95% of response time, meaning that 95% transactions were finished under the given time.

OLTP Readonly response time, 95th percentile

Concurrent clients 4 8 16 32 64 128 256 512 1024 2048 4096
MariaDB 4.87 6.81 8.83 12.35 22.12 43.56 90.35 180.57 619.05 1003.88 1965.77
MySQL 4.86 7.14 9.96 16.21 37.39 101.33 238.89 499.63 971.07 2241.83 25215.29

As the above table shows, MariaDB 5.5 outperforms MySQL 5.5 in both row throughput, and in fairness. Fairness (response time) results are in fact more impressive than the row throughput.

But, why does MariaDB perform better than MySQL 5.5 on Windows in readonly tests? Why it is at all better than 5.5? It is, after all, based on the same codebase, so performance should be about equal. The answer to this is not our optimizer enhancements, nor XtraDB serving as InnoDB in MariaDB. The answer is the MariaDB threadpool. This is my feature in 5.5 and I’m glad it performs so well, and I’m glad that it is switched “on” by default on Windows (so, Windows users, you do not have to do anything to switch it on).

Still, why does using threadpool result in such better performance? The answer is that the implementation delegates all responsibility for sizing the pool and running callbacks to the Windows native threadpool, so it is a sort of black box inside the OS that just delivers good results. The heart of the Windows native threadpool, if you want to know, is the good old IO completion port, something that Windows has had since the NT 3.5 days. It’s a unique Windows feature, and something that any server application running on this platform is using or should be using. And the tricks that make it run well are:

  • It does not let too many threads run “on CPU” at the same time (this reduces context switches). Reducing context switches is, in my experience, the single most important factor to increasing throughput.
  • It activates threads waiting on completion LIFO order — hot threads remain hot, which reduces cache misses
  • IO completions are processed in FIFO order — this is why fairness performance is so good
  • And yes, it naturally reduces contention on hot locks.

Enough about readonly performance already, and about threadpool.

The next interesting question is whether MariaDB can do as well on write workloads. So let’s run the sysbench in the ultimate “write-only” mode, also known as update_non_index (every query only increments a non-indexed int column). To maximize the write throughput, I set the innodb_flush_log_at_trx_commit parameter to 0, so the log is flushed once a second rather than each time at transaction commit.

Here are the results:

OLTP write-only (update_non_index/flush_log=0) throughput:

This looks pretty good. The difference could be a combination of many factors. XtraDB write performance, group commit, and threadpool could all have a positive (for MariaDB) influence on the results. However I think the Windows version of MariaDB’s asynchronous IO optimization (it, again, uses completion ports) is the main reason for the big difference here. I, actually, first saw the difference when I was implementing the feature.

All IO related parameters and Innodb parameters in the test above are default. The result looks almost too good to be true, so I really wanted to bring MySQL to the point it can achieve better IO throughput by varying innodb_io_capacity and/or innodb_write_io_threads, to no avail. Does someone know the right trick here?

OLTP writeonly (update_non_index/flush_log=0) response time, 95 percentile

Concurrent clients 4 8 16 32 64 128 256 512 1024 2048
MariaDB 0.33 0.63 0.75 1.06 1.94 3.85 8.25 21.38 129.79 274.40
MySQL 0.32 0.61 0.73 1.61 7.62 26.82 96.45 219.29 661.19 2723.36

For completeness, here are database parameters I’m using.

[mysqld]
sql-mode="NO_ENGINE_SUBSTITUTION"
back_log=500
user=root
port=3306
max_connections=4096
max_connect_errors=5000
max_prepared_stmt_count=50000
table_cache=2048
transaction_isolation=REPEATABLE-READ
loose-skip-external-locking
innodb_status_file=0
innodb_data_file_path=ibdata1:200M:autoextend
innodb_buffer_pool_size=1G
innodb_additional_mem_pool_size=20M
innodb_log_file_size=650M
innodb_log_buffer_size=100M
innodb_support_xa=0
innodb_doublewrite=0
innodb_flush_log_at_trx_commit=0
query-cache-size=0
query-cache-type=0
symbolic-links=0
skip-grant-tables