My analysis was based on benchmarks and described in a few blog posts. This is interesting for a few reasons. 1) replication is single-threaded at least for a few more years. Eventually we will all have the Kristian-inspired idea of getting parallel replication apply even when there is only one database shard and that helps some. But there are always some workloads that really are single threaded on the master and during replication apply. 2) fast storage means that IO-bound workloads might be able to get 100,000+ IOPs on a commodity server. So even when IO-bound we need much higher throughput in the past 3) At least with public-facing information Oracle doesn't write about this topic. Their performance focus is high concurrency. 4) RAM per host is much larger so more workloads are not IO bound and expect high throughput I don't think a complex workload is needed to show the problem. sysbench and dbt might be sufficient. linkbench should also be useful to MariaDB. http://mysqlha.blogspot.com/2013/09/mysql-41-forever.html http://mysqlha.blogspot.com/2013/09/single-threaded-connect-performance.html http://mysqlha.blogspot.com/2013/09/mysql-572-single-threaded-performance.ht... http://mysqlha.blogspot.com/2013/05/mysql-56-single-threaded-performance.htm... http://mysqlha.blogspot.com/2013/05/mysql-56-versus-40-for-read-only.html http://mysqlha.blogspot.com/2013/04/mysql-56-single-thread-update-only.html http://mysqlha.blogspot.com/2013/03/mysql-56-single-threaded-read-only.html On Mon, Jan 20, 2014 at 8:18 AM, Sergey Vojtovich <svoj@mariadb.org> wrote:
Hi Mark,
we identified a few single-thread performance issues during the Barcelona meeting. Monty should have them fixed in his private tree. Fixes are quite generic and should improve performance almost in all cases. An exception is bottlenecks specific to certain use cases.
Could you send me any relevant information my way if you have it around?
Thanks, Sergey
Are there other goals for single-thread performance regressions? There are many that have nothing to do with replication code although almost every single-threaded replication hurts replication.
On Mon, Jan 20, 2014 at 2:54 AM, Axel Schwenke <axel@askmonty.org> wrote:
Hi,
for those of you who didn't attend the Barcelona meeting last week, here are the plans for next steps in benchmarking:
1. top priority is automatic running of DBT3 for each new release of MariaDB-10.0 and MySQL-5.6. Probably also for MariaDB-5.5. I'll send out another mail to pinpoint DBT3 conditions (i.e. which table statistics to use etc.)
2. multithreaded replication slave is now in a condition that it can and should be benchmarked
3. the problem pointed out by Yoshinori in
http://yoshinorimatsunobu.blogspot.de/2013/12/single-thread-performance-regr...
must be checked for MariaDB. Monty announced that he will commit a
On Mon, Jan 20, 2014 at 08:00:45AM -0800, MARK CALLAGHAN wrote: patch
this week that should help with that problem.
4. for the NUMA scalability problem, Kristian will try to find the definitive reason with profiling tools. Besides that ad-hoc testing of new patches from Svoj continues as before.
5. Galera benchmarking will be done by the Galera team for now.
XL
_______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
-- Mark Callaghan mdcallag@gmail.com
_______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
-- Mark Callaghan mdcallag@gmail.com