Merge lp:~akopytov/percona-server/bug1163439-5.6 into lp:percona-server/5.6
Status: | Merged |
---|---|
Approved by: | Laurynas Biveinis |
Approved revision: | no longer in the source branch. |
Merged at revision: | 328 |
Proposed branch: | lp:~akopytov/percona-server/bug1163439-5.6 |
Merge into: | lp:percona-server/5.6 |
Diff against target: |
137 lines (+41/-14) 4 files modified
Percona-Server/storage/innobase/include/log0log.h (+12/-4) Percona-Server/storage/innobase/include/log0log.ic (+19/-4) Percona-Server/storage/innobase/log/log0log.cc (+7/-5) Percona-Server/storage/innobase/mtr/mtr0mtr.cc (+3/-1) |
To merge this branch: | bzr merge lp:~akopytov/percona-server/bug1163439-5.6 |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Laurynas Biveinis (community) | Approve | ||
Review via email: mp+156740@code.launchpad.net |
Description of the change
Bug #1163439: Unnecessary log_sys->mutex reacquisition in
mtr_log_
to log_sys->mutex: if the mini-transaction log contains a single block,
it calls log_reserve_
does a "fast" write by appending the new record to the current log
block. If the record does not fit in the current log block,
log_reserve_
which case mtr_log_
log_sys->mutex by calling log_reserve_
"slow" write procedure.
It doesn't make sense to release a mutex and reacquire it immediately
and benchmarks show that avoiding this helps to reduce log_sys->mutex
contention in some write-intensive workloads.
Fixed by implementing an alternative to log_reserve_
doesn't acquire the mutex (log_open()), removing mutex_exit() from
log_reserve_
current block, and using log_open() instead of log_reserve_
mtr_log_
http://
Looks good, the only question is whether an upstream bug should be logged, asked on the bug report itself.