Details
-
Type:
Task
-
Status: Open
-
Priority:
Major
-
Resolution: Unresolved
-
Fix Version/s: None
-
Component/s: Replication
-
Labels:None
Description
from Pavel Ivanov on mailing list in reference to parallel replication:
> some status variables which could be plotted over time and show (or at
> least hint on) whether this is significant bottleneck for performance
> or not.
> This could be something like total time (in both wall time and
> accumulated CPU time) spent executing transactions in parallel, time
> spent rolling back transactions due to this lock conflict, time spent
> rolling back transactions because of other reasons (e.g. due to STOP
> SLAVE or reconnect after master crash), maybe also time spent waiting
> in one parallel thread while transaction is executing in another
> thread, etc.
Gliffy Diagrams
Attachments
Issue Links
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
I made a patch that adds some status variables, measuring time spent by
worker threads being idle, processing events, and waiting for other
transactions:
http://lists.askmonty.org/pipermail/commits/2015-July/008126.html
More details in the commit message in the link. This is not necessarily
meant to be the final form (or any form) of this MDEV-7340, but it might be
interesting, at least. Testing of the patch welcome.
nice. Thank you. Was looking to see if anything other than status_lock could be used but like you didn't see an easy approach. status vars look good.
Do you mean LOCK_status?
statistic_add(*current_status_var,
new_time - slave_worker_phase_start_time, &LOCK_status);
If my understanding is correct, this statistic_add compiles into an atomic
add operation on platforms of interest. The lock is not actually used,
unless some wierd platform that does not have atomic operations.
EDIT: Actually, it appears that neither lock nor atomic operations are
used. There is a SAFE_STATISTICS define that causes them to be used, but it
is never enabled. So there is no locking apparently, and the statistics can
at least theoretically be off, trading 100% accuracy for improved
performance.
thanks for looking this up.
I'm quite happy with this tradeoff.
If you're happy with its final form any chance of a backport? It applies to 10.0 with minimal fuzz.
Any chance of a port to 10.0? I don't particularly care if it changes sightly in the future. Something is better than nothing.
from
MDEV-7396- max consecutive parallel deadlocks is probably useful