-
-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug] Deadlock on option table using log importer #21414
Comments
Thanks for the detailed report @lato333. There have been recent optimizations to the archiving process made in Matomo 5 which could potentially help with this issue. Do the deadlocks still happen if the import command is run with |
Thanks for the fast reply, I will give it a try. |
Unfortunately, the same issue occurs with Matomo 5. Setting the recorders to 1 would probably resolve the deadlocks, but with that option set, I will run into time problems. Thanks! |
@lato333 Is your setup maybe a very old one and your database tables are still using MyISAM storage engine? If so, updating to InnoDB could help maybe. |
@sgiehl Unfortunately not, all tables are stored using the InnoDB storage engine. |
Hm. Are you importing data that is older than yesterday? |
It is a bit hard to reproduce, but it also occurs on the current daily rotated logfiles. ( |
Guess it might be hard to identify the root cause of this. I would assume it might be the amount of requests being performed in parallel. Maybe using the QueuedTracking plugin could solve the problem: https://plugins.matomo.org/QueuedTracking |
Unfortunately, QueuedTracking did not work with the log importing, as I get tracking errors. Nevertheless, thanks for the help. |
Long shot, but do you have any scheduled archiving process (ie. the Matomo cronjob) that could be starting up during the import and causing the deadlocks? |
No, each log (for different sites) is imported sequentially with multiple recorders. Afterwards, when all logs are imported, the archiving process is called. Pseudocode:
No cronjob is defined and the archiving via browser is disabled. Regular deletion of old raw data is turned on, maybe this could be an issue? |
If there is no cronjob configured and browser archiving is disabled then the deletion of old raw data will only run when archiving is called manually (scheduled tasks run at the end of the archiving process). It looks like the deadlock is occurring when a temporary option is written to remember archives that need to be invalidated later on in the process. There is a source code comment which explains the contention risk and that it should be mitigated by suffixing the process id to the temporary option name. From the debug information you provided, the problem insert statement used the option name: Each recorder will be adding many visits and as part of adding each visit an option is inserted, since the process id will always be the same for each recorder then the only protection against collision will be the random string prefix. It seems unlikely, but perhaps with enough records being processed a four byte random prefix is insufficient and could repeat within the same process, the random string currently has 61 possible characters and four bytes giving 1,345,841 possible combinations. If you are comfortable making a very minor change to code, then you could try changing the random string length from 4 bytes to 8 bytes here and see if that improves things.
|
Thanks for the detailed analysis and report, this makes sense to me. I will give it a try! |
Unfortunately, the issue remains with the recommended change.
|
Thanks for getting back with the outcome @lato333. unfortunate that change didn't fix it, but every bit of additional information is helpful 👍 |
What happened?
Hello,
I am experiencing the closed issue (#15545) - Unfortunately, I could not reopen it.
Details see #15545 (comment)
Thanks!
What should happen?
Import without deadlocks.
How can this be reproduced?
Using the following command on large logfiles:
/usr/bin/python ./misc/log-analytics/import_logs.py --recorders 5 --url=<url> --enable-static --enable-http-redirects --idsite=<id> --token-auth <token> <filename>
Matomo Version
Matomo 3
Matomo Patch or Minor Version
4.15.1
PHP Version
PHP 8.1.2-1ubuntu2.14 (cli) (built: Aug 18 2023 11:41:11) (NTS)
Server Operating System
Ubuntu 22.04
What browsers are you seeing the problem on?
Not applicable (e.g. an API call etc.)
Computer Operating System
Relevant log output
No response
Validations
The text was updated successfully, but these errors were encountered: