Details
-
Bug
-
Status: Needs Feedback (View Workflow)
-
Major
-
Resolution: Unresolved
-
10.4(EOL), 10.5, 10.6, 10.11, 11.4
-
None
-
None
-
Linux
Description
And it looks like MariaDB (tested
10.4, 10.5, 10.6 so far) suffers from a bug.
Setup:
sloq_query_log=1
log_slow_verbosity=query_plan,explain
long_query_time=0
sysbench oltp_read_write --threads=$(nproc)
|
Action:
\!mv slow.log slow.log.1
|
flush slow logs;
|
^^ This typically takes > 10 minutes
On MySQL and MariaDB 5.5 this is instantaneous. On 5.6 - 8.0 it takes a few
seconds, worst case I measured over the weekend is 77s, which is
pretty terrible, but with MariaDB 10.4 - 11.4 it never seems to
complete at all.
If I kill sysbench, it completes immediately.
On 10.3 it works, in line with MySQL 5.6 - 8.0. Slow (I would expect this to be instantaneous, like it was in 5.5), but at least it completes in a reasonable amount of time most of the time.
Whatever the cause, it got substantially worse in 10.4.34.
With 10.4.0-10.4.33 it isn't great, but it typically finishes in
between a few seconds up to 5 minutes.
With 10.4.34, it never finishes in the seconds, I saw only one example
in hours of testing where `flush slow logs;` under heavy load
completed in under a minute, in most cases it takes upward of 10
minutes.
A very bad workaround is something like this:
set global slow_query_log=0;
|
\!mv slow.log slow.log.1
|
flush slow logs;
|
set global slow_query_log=1;
|
but the big problem with that is that it is lossy - the above operation is not atomic, so some queries will be omitted from the log.