Michael Widenius writes:

...

On the master, I implemented --binlog-commit-wait-count=N and --binlog-commit-wait-usec=T. A transaction will wait at most T microseconds for at least N transactions to queue up and be ready for group commit. This allows to deliberately delay transactions on the master in order to get bigger group commits and thus better opportunity for parallel execution (and again it makes testing easier).

Do you think the above helps in any real world case, except testing?

Assuming we are have N=4 and T=2

- We have 3 threads ready to commit - We wait 2 milliseconds and get 2 more threads. - We commit now 5 threads. During this time you get 3 other threads waiting to commit. - We wait again...

In a scenario without waiting:

- We have 3 threads ready to commit - We commit 3 threads. During this time we get 5 more threads waiting to commit. - We commit 5 threads.

In other words, as the group commit will anyway take up 50 microseconds on a hard disk, and thus automaticly group things together for the next commit, why do we need ever to wait more?

I agree that with --binlog-commit-wait-count you may get less sync calls, but at an expense that a lot of threads took up to T microseconds longer to execute.

The worst case scenario is when you have only one user doing a lot of inserts with auto-commit. In this case using wait will slow down the server with T microseconds for every query.

Have you been able to run any kind of benchmark where using binglog-commit-wait-count will give more performance?

I agree that the options are good for testing. The main question I have is if we want to have the variables in the production server and how we should document when and how a user should use the variables.

I agree that with respect to group commit, the --binlog-commit-wait-count in many cases will not improve performance (that is why I did not implement it earlier). However, for parallel replication things are a bit different. Suppose that the application is doing C transaction commits per second, and that the disk system is capable of F binlog fsyncs per second. Now, if C is significantly bigger than F, then things are as you describe. Generally several transactions will queue up while the previous group commit runs, and there will be sufficient parallelism without using --bicommit_wait-*. This will be typical for eg. a simple harddisk-based system (F=40 commits/second perhaps) where all data is cached in the InnoDB buffer pool (eg. C>500 transactions/second). On the other hand, if C is smaller than F (or of similar magnitide), then usually only few or no new transactions will have time to queue up while the previous transaction is committing. So there will not be much parallelism for parallel replication to exploit without using --binlog-commit-wait-*. This will be typical for eg. a good-quality server with battery-backup RAID controller (F > 1000 commits/second) where data is too big to fit in buffer pool and every update requires disk access to complete (C < 500 transactions/second for example). And in fact, it is the second case, where random I/O is the bottleneck and multiple disk spindels are needed to improve I/O throughput, that single-threaded slave hurts the most, and where increasing --binlog-commit-wait-usec can be used with least penalty. I agree we need to document clearly the risk that --binlog-commit-wait-* will decrease performance on the master. Basically, the user can look at the ratio of Binlog_commits and Binlog_group_commits to check if enough transactions are part of each group commit for parallel replication to be effective.

...

1. The existing code is not thread-safe for class Relay_log_info. This class contains a bunch of stuff that is specific to executed transactions, not related to relay-log at all. This needs to be moved to the new struct rpl_group_info I introduced, and all code updated to pass around a pointer to that struct instead. There may also be a need to add additional locking on Relay_log_info, existing code needs review for this.

I could take a look working on the above tomorrow and next week.

Ok, great. Ping me when you can so we can coordinate, I may have some partial patches for this lying around. - Kristian.