[MDEV-30274] Massive trigger performance drop after update Created: 2022-12-19 Updated: 2022-12-20 Resolved: 2022-12-20 |
|
| Status: | Closed |
| Project: | MariaDB Server |
| Component/s: | Stored routines, Triggers |
| Affects Version/s: | 10.6.11 |
| Fix Version/s: | 10.11.2, 10.3.38, 10.4.28, 10.5.19, 10.6.12, 10.7.8, 10.8.7, 10.9.5, 10.10.3 |
| Type: | Bug | Priority: | Major |
| Reporter: | Andreas Pillath | Assignee: | Sergei Golubchik |
| Resolution: | Duplicate | Votes: | 2 |
| Labels: | regression | ||
| Environment: |
Official MariaDB 10.6.10/11 Docker Images and MariaDB 10.6.11 client on Ubuntu 22.4 |
||
| Attachments: |
|
||||||||
| Issue Links: |
|
||||||||
| Description |
|
We discovered a performance degration after updating from 10.6.10 to 10.6.11:
The issue is reproducible with the attached 'test.sql' script. The update without a trigger is not affected.
The server was started in a container with
Addtional observation: when looking at the strace output of the mariadb-process, there seem to be many futex-ETIMEDOUT errors with a duration of 0.1-0.4secs.
|
| Comments |
| Comment by Sergei Golubchik [ 2022-12-19 ] | ||||||||||||||||||||||||||||||||||||||||||||
|
I don't seem to be able to repeat this issue.
And on 10.6.11 it was
t1 is slower, because you've created an index there. If I remove ALTER TABLE, I can the timing within ±1sec. May be it's something specific to your setup? Like, depending on your my.cnf settings? | ||||||||||||||||||||||||||||||||||||||||||||
| Comment by Andreas Pillath [ 2022-12-20 ] | ||||||||||||||||||||||||||||||||||||||||||||
|
@serg Sorry, there have been two flaws(wrong index and nondeterministic) in the script, hopefully you will now also be able to reproduce the problem with the attached testv2.sql script. It is now also printing the affected rows which have been random before.
When looking at the mariadbd process during the update with gdb, it seems to be stuck at the following location:
| ||||||||||||||||||||||||||||||||||||||||||||
| Comment by Valerii Kravchuk [ 2022-12-20 ] | ||||||||||||||||||||||||||||||||||||||||||||
|
If the time is spent in cleanup_items(), it is probably a yet another duplicate of | ||||||||||||||||||||||||||||||||||||||||||||
| Comment by Andreas Pillath [ 2022-12-20 ] | ||||||||||||||||||||||||||||||||||||||||||||
|
| ||||||||||||||||||||||||||||||||||||||||||||
| Comment by Sergei Golubchik [ 2022-12-20 ] | ||||||||||||||||||||||||||||||||||||||||||||
|
valerii, right, looks like it is. I was trying to repeat it one commit before the fix to see if it'll disappear after the fix, but failed to repeat it even on vanilla 10.6.10. But now with the perf data, I'm fairly certain you're right. It's pskiwi, thanks. I'll close this as a duplicate now. Note that If you need a workaround, try to avoid implicit charset conversions in the trigger. Perhaps the connection character set (and thus '') is utf8, but txt in the table is latin1, or vice versa? An explicit CONVERT() should help to avoid the buggy code path. |