from pivanof 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.
Attachments
Issue Links
duplicates
MDEV-7202[PATCH] additional statistics for parallel replication - Slave_parallel_eventqueue_size/Slave_parallel_eventqueue_freepending
Closed
relates to
MDEV-5296No status information available for parallel replication
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.
Daniel Black
added a comment - 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.
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.
Kristian Nielsen
added a comment - - edited 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.
If you're happy with its final form any chance of a backport? It applies to 10.0 with minimal fuzz.
Daniel Black
added a comment - 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.
Daniel Black
added a comment - 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.
Task
Major
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.