Alongside SkySQL, we participate in SkySQL & MariaDB Meetups. These events are free to attend and you’ll get to meet & speak with SkySQL CEO Patrik Sallner and all round MariaDB man (& MySQL creator) Michael “Monty” Widenius. 

  1. Roadshow in Amsterdam, the Netherlands – 21 March 2013
  2. Roadshow in Paris, France – 27 March 2013

If you’re at the Percona Live MySQL Conference & Expo Santa Clara (many of us from Team MariaDB are speaking), you should consider spending the extra day there as on Friday April 26 2013, there exists the SkySQL & MariaDB Global Roadshow 2013. It’s also free to attend, so even if you can’t attend all week, consider just coming on Friday.

The MariaDB Java Client 1.1.1 has been released. You can download it here.

See the Release Notes and Changelog for detailed information on this release and the About the MariaDB Java Client page in the AskMonty Knowledgebase for general information about the client.

New functionality in this release

  • Implement tcpAbortiveClose option, for “hard” socket close (CONJ-27)
    • This option can be used in environments where connections are created and closed in rapid succession. Often, it is not possible to create a socket in such environment after a while, since all local “ephemeral” ports are used up by TCP connections in TCP_WAIT state. Using tcpAbortiveClose works around this problem by resetting TCP connections rather (abortive or hard close) than doing an orderly close. It is accomplished by using socket.setSoLinger(true,0) for abortive close.

Bugs fixed in this release

  • MySQLStatement will now indicate there are no more results by returning -1 from getUpdateCount() and null from getResultSet(),as mandated by the standard (CONJ-14)
  • Introduced nullCatalogMeansCurrent parameter for compatibly with ConnectorJ, and make it default (CONJ-16)
    • Prior to this change, DatabaseMetadata.getTables() or other methods of DatabaseMetaData that accept catalog names and return result sets would treat null as prescribed by the JDBC standard (null means no restriction which catalog is used). This behavior is now changed for the sake of compatibility. Starting with 1.1.1 , null for catalog name will mean current catalog. To get JDBC standard behavior, one needs to set nullCatalogMeansCurrent=false.
  • DatabaseMedataData.getColumns() returned incorrect values in the “COLUMN_SIZE” column for character data.(CONJ-15))
    • Prior to the change, octet size was returned (length in bytes). Depending on the character set used, it could be 3 times bigger than the length in characters that was specified by CREATE or ALTER table. This behavior is corrected in 1.1.1
  • DatabaseMetaData.getColumns() always handled MySQL YEAR datatype as SMALLINT. (CONJ-19)
    • The behavior is now fixed and getColumns returns either DATE or SMALLINT depending on how the ‘yearIsDateType’ parameter is set.
  • ResultSetMetaData.getColumnName() returned an empty string in special cases (CONJ-17)
    • ResultSetMetaData.getColumnName() returned and empty string for “non-columns” in a result set (functions, aggregates like count(*), and so on). The fix is to return the column label to be returned if the column name is empty.
  • Ensure that getObject() returns byte array for CHAR BINARY.(CONJ-20)
    • Also make sure that getColumnType(),getColumnClassName(),getColumnTypeName() return values indicate BINARY for fixed binary type.
  • JVM does not exit if statement timeout is used.(CONJ-23)
    • Constructor for Timer was corrected to ensure that the Timer thread has type background thread. Thus Timer won’t prevent JVM from exiting.
  • Calling first() on “streaming” result set and using the result set afterwards generated NullPointerException (CONJ-24)
    • Now a SQLException is thrown early on, in the first() call, since streaming results sets are not scrollable.
  • Connection.close() hangs if there is an open streaming result set, and next() was not called on this result set (CONJ-25)

 

Oracle has now launched MySQL-5.6.10-GA, so it is time to come up with some new benchmark results. The test candidates in this benchmark run are

  • MySQL-5.5.29
  • MySQL-5.6.10
  • MariaDB-5.5.28a
  • MariaDB-10.0.1

The 5.5 versions are in because I wanted to check for any regressions. In the past we have often seen performance regressions in newer versions which were caused by new features.

This time the benchmark was run on a different box. The main difference is that this box does not have SSD but a high performance RAID-5 with 512M of battery-backed cache. Besides that the machine has 16 cores out of which 12 were used for mysqld and the other 4 for sysbench.

The benchmark uses sysbench-0.5 OLTP with 8 tables and 10G worth of data. InnoDB buffer pool was 16G, InnoDB log group capacity 4G (the maximum for MySQL-5.5). The different disk system required different InnoDB configuration:

  • innodb_io_capacity = 1000 (was 20000 for SSD)
  • innodb_flush_neighbors = 1 (was 0 for SSD)

Now for the results. OLTP read only comes first:

20130213-sb-ro-tps

And here is the first surprise: MySQL-5.6 behaves significantly different. It competes well up to 8 threads, it even wins 16 threads. But at higher concurrency performance drops off rapidly, even compared to MySQL-5.5. MariaDB-10.0 shows also a slight drop in performance compared to MariaDB-5.5, but it’s much less pronounced.

The response time graph is nice and smooth though:

20130213-sb-ro-rt

Both MySQL-5.6 and MariaDB-10.0 look a little better which means they distribute cpu cycles more evenly on concurrent requests.

Disclaimer: no thread pool was used in this benchmark. The Oracle implementation of the thread pool is closed source and thus cannot be benchmarked or used by anybody. It seemed a bit unfair to use the MariaDB thread pool under those cirumstances.

If you want to see the impact of the MariaDB thread pool, have a look at the benchmarks published previously:

Next stop: OLTP read/write:

20130213-sb-rw-tps

The picture is very similar. Both MySQL-5.6 and MariaDB-10.0 show a performance drop, compared to the 5.5 versions. For MySQL the drop is more than 10% and thus rather heavy.

However it’s a well known fact that MySQL-5.5 exhibits severe write stalls under high load when InnoDB starts synchronous flushing. The response time graph is good to spot this:

20130213-sb-rw-rt

This is the good news. While the 5.5 versions both show heavy write stalls at 64 threads and more, the behavior is much less pronounced with MySQL-5.6 and MariaDB-10.0. So it seems the new adaptive flushing algorithm is working well.

There is however one problem here: if you use multiple buffer pool instances, then you see write stalls more often. For the above results I have run the read-only tests with 16 buffer pools and the read-write tests with only 1.

Conclusions:

  • MySQL-5.6 shows a rather severe performance regression, especially at higher concurrency levels. This does not match the results published by Oracle. I can only speculate why the results are so different, but I guess it’s the (closed source) thread pool and maybe the fact that Oracle benchmarks were done on much bigger hardware.
  • with a single buffer pool you don’t have to be afraid of write stalls any more. Also MySQL-5.6 allows now up to 512G redo log capacity which further reduces the odds to run into synchronous flushing (MariaDB-5.5 lifted this limit with XtraDB already)

As always the scripts used for the benchmark as well as the results are available from launchpad:

http://bazaar.launchpad.net/~ahel/maria/mariadb-benchmarks/revision/20

I invite anybody to rerun this benchmark and share the results.