Details
-
Task
-
Status: Closed (View Workflow)
-
Minor
-
Resolution: Fixed
Description
currently we have a status variable for the total group_commits. This compromises of group commits due to binlog_commit_wait_count, binlog_commit_wait_usec or indeed conflicting transactions that need to be in a separate group.
Showing a breakdown as to the reason of the group commit will enable a more informed tuning of the system variables controlling the group commit and also identify how often these aren't taking part in the group determination.
Attachments
Issue Links
- relates to
-
MDEV-7249 Performance problem in parallel replication with multi-level slaves
-
- Closed
-
Activity
responded and corrected in github PR: https://lists.launchpad.net/maria-developers/msg08405.html
Thanks, Daniel.
The patch is ok. Though I will remove the test case in
rpl_parallel_multilevel2, I think. The 2-second timeout could trigger on
highly loaded test hosts, which looks like it will make the test case
fail. And I don't think the test adds anything really critical over what's
in binlog_commit_wait.test.
So I will push it into 10.1, however I need to first resolve a merge problem
that is blocking the push...
The patch is ok. Though I will remove the test case in
rpl_parallel_multilevel2, I think. The 2-second timeout could trigger on
highly loaded test hosts, which looks like it will make the test case
fail. And I don't think the test adds anything really critical over what's
in binlog_commit_wait.test.
Ok - was my description on the multilevel for the reason between 1 and 3 groups right? I felt I was guessing a bit.
https://github.com/MariaDB/server/pull/30/files#diff-343103ed05549066b0de2beb82b16496R77
So I will push it into 10.1, however I need to first resolve a merge problem that is blocking the push...
to help that along...
https://github.com/MariaDB/server/pull/43 - single merge
https://github.com/MariaDB/server/pull/42 - entire 10.0 -> 10.1
Pushed to 10.1.5. Thanks, Daniel!
Welcome. Thanks for the merge.
Any chance of getting this into 10.0? seems like the most invasive bit is the extra brief lock on LOCK_prepare_ordered when when fetching status variables.
> Any chance of getting this into 10.0? seems like the most invasive bit is
> the extra brief lock on LOCK_prepare_ordered when when fetching status
> variables.
Probably you should ask this on the maria-developers@ mailing list. I don't
personally have any strong opinion one way or the other.
The "normal" policy is to not introduce new features in stable releases.
> I've added status variables to the KB.
Thanks, Daniel, much appreciated.
See review comments on maria-developers@