Hi @wppraesenz,
Thanks for being a longtime user of ODADR! π
Self-hosted analytics tools like Matomo have to store a lot of data, and there are other factors that impact performance besides sheer size of a table. It sounds like these tables may be either too big, or perhaps too complicated in some other way, for your server to be able to rebuild/optimize them.
I don’t know if Matomo allows this, but perhaps you could retain less data? For example, maybe keep 90 days instead of a year? But you’d need to contact them for more specific help with this, since our plugin just tells the server to run the optimization — and fixing issues with a specific table would be outside our scope or ability. You can open a support thread with them here: https://ww.wp.xz.cn/support/plugin/matomo/
In the meantime, as a workaround you could exclude those tables from optimization, so you can optimize all your other InnoDB tables if need be.
In Settings > Optimize Database > Exclude Database Tables from Optimization, you can check the box next to each Matomo table to ignore. We checked the Matomo plugin’s code, and here’s a list of all the tables it uses:
(replace wp_ with your table prefix)
wp_access
wp_archive_blob
wp_archive_invalidations
wp_archive_numeric
wp_brute_force_log
wp_changes
wp_goal
wp_locks
wp_log_action
wp_log_conversion
wp_log_conversion_item
wp_log_link_visit_action
wp_log_profiling
wp_log_visit
wp_logger_message
wp_option
wp_plugin_setting
wp_sequence
wp_session
wp_site
wp_site_setting
wp_site_url
wp_tracking_failure
wp_twofactor_recovery_code
wp_user
wp_user_token_auth
Since troubleshooting these tables is outside our scope and better-suited for Matomo to assist, I’m going to mark this as resolved…but I hope this helped point you in the right direction, or at least gave you a workaround!
Best,
Andrew
Thread Starter
wpprup
(@wppraesenz)
Dear Andrew,
thank you very much for your help!
Great, I will try both: keeping the Matomo support busy and in the meantime excluding the bad bad Matomo files… π
Best wishes!