wp-rocket
wp-rocket copied to clipboard
wp-media
Deadlock found when trying to get lock (UPDATE prefix_actionscheduler_actions)
Describe the bug Without apparent regularity nor reproducibility (timing issue), our log now carries anything to 1-2 dozen mentions of this per day (dates & action_id varying ofc):
WordPress database error Deadlock found when trying to get lock; try restarting transaction for query UPDATE {prefix}_actionscheduler_actions SET attempts = attempts+1, status='in-progress', last_attempt_gmt = '2022-08-29 15:34:51', last_attempt_local = '2022-08-29 17:34:51' WHERE action_id = 76956 von do_action('wp_ajax_nopriv_as_async_request_queue_runner'), WP_Hook->do_action, WP_Hook->apply_filters, WP_Async_Request->maybe_handle, ActionScheduler_AsyncRequest_QueueRunner->handle, do_action('action_scheduler_run_queue'), WP_Hook->do_action, WP_Hook->apply_filters, ActionScheduler_QueueRunner->run, ActionScheduler_QueueRunner->do_batch, ActionScheduler_Abstract_QueueRunner->process_action, ActionScheduler_DBStore->log_execution
I'm not sure at all whether this is actually due to WP Rocket, but it seems 50/50 as we only have three plugins packing the ActionScheduler: WooCommerce, WP-R, WPForms Lite
WooCommerce's support denied it's them, instead placing blame on a plugin/theme locking the DB table because it didn’t finish updating a record. Our Divi doesn't appear to use the scheduler.
Both WP-R & WPF received updates recently, but WPF's most recent one was two weeks ago when the issue wasn't yet occurring.
To Reproduce Steps to reproduce the behavior:
- No reproducibility found
Expected behavior No error messages in the log.
Additional context No actual negative impact noticed (yet).
No failed entries in WooCommerce's Status's "Scheduled Actions" nor other error logs.
WC 6.8.2 WP-R 3.12.0.4 WPForms Lite 1.7.6 Theme: Divi 4.18.0 WP 6.0.2 PHP 8.1.8
Backlog Grooming (for WP Media dev team use only)
- [ ] Reproduce the problem
- [ ] Identify the root cause
- [ ] Scope a solution
- [ ] Estimate the effort
Site ran without WP Rocket for 24h and no new errors occurred. So I'm leaning towards the plugin indeed being the cause.
I've deleted an entry in cron/AS leftover by WP-R despite the deactivation & will now reactivate it again to check further.
Related:
- https://secure.helpscout.net/conversation/2000637515/366629/
- https://secure.helpscout.net/conversation/1985640222/363222/
- https://secure.helpscout.net/conversation/1998433981/365950/
- https://secure.helpscout.net/conversation/1986834892/363497/
Since I can't see those, could you please tell me whether they contain signs (recency, more details, etc.) that this is actually a WP-R issue? Or even workarounds?
I still have no clue where it's actually coming from, seeing there's zero further details in the WP's debug.log nor (have I been able to find) really helpful resources on the net.
I'm not sure if this is related: Rather than deadlocks, I'm now getting sporadic out-of-memory errors on 3.12.1.
We've got 256M and this has never happened in 2y+. We don't have many plugins either and all optional ones are disabled.
A couple of similar errors:
[15-Aug-2022 02:05:35 UTC] WordPress database error Deadlock found when trying to get lock; try restarting transaction for query DELETE FROM `wp_options` WHERE `option_name` = '_transient_wp_rocket_customer_data' made by require('wp-blog-header.php'), require_once('wp-load.php'), require_once('wp-config.php'), require_once('wp-settings.php'), do_action('plugins_loaded'), WP_Hook->do_action, WP_Hook->apply_filters, rocket_init, WP_Rocket\Plugin->load, WP_Rocket\Dependencies\League\Container\Container->get, WP_Rocket\Dependencies\League\Container\ServiceProvider\ServiceProviderAggregate->register, WP_Rocket\Engine\License\ServiceProvider->register, WP_Rocket\Engine\License\API\UserClient->get_user_data, get_transient, delete_option
[15-Aug-2022 12:23:32 UTC] WordPress database error Deadlock found when trying to get lock; try restarting transaction for query DELETE FROM `wp_options` WHERE `option_name` = '_transient_wp_rocket_pricing' made by require('wp-blog-header.php'), require_once('wp-load.php'), require_once('wp-config.php'), require_once('wp-settings.php'), do_action('plugins_loaded'), WP_Hook->do_action, WP_Hook->apply_filters, rocket_init, WP_Rocket\Plugin->load, WP_Rocket\Dependencies\League\Container\Container->get, WP_Rocket\Dependencies\League\Container\ServiceProvider\ServiceProviderAggregate->register, WP_Rocket\Engine\License\ServiceProvider->register, WP_Rocket\Engine\License\API\PricingClient->get_pricing_data, get_transient, delete_option
[15-Aug-2022 02:05:35 UTC] WordPress database error Deadlock found when trying to get lock; try restarting transaction for query DELETE FROM `wp_options` WHERE `option_name` = '_transient_timeout_wp_rocket_customer_data' made by require('wp-blog-header.php'), require_once('wp-load.php'), require_once('wp-config.php'), require_once('wp-settings.php'), do_action('plugins_loaded'), WP_Hook->do_action, WP_Hook->apply_filters, rocket_init, WP_Rocket\Plugin->load, WP_Rocket\Dependencies\League\Container\Container->get, WP_Rocket\Dependencies\League\Container\ServiceProvider\ServiceProviderAggregate->register, WP_Rocket\Engine\License\ServiceProvider->register, WP_Rocket\Engine\License\API\UserClient->get_user_data, get_transient, delete_option
The issue is more related to the server and its ability to process requests.
If any of our requests is deadlocked, there will very likely be other requests from other plugins deadlocked as well.
@piotrbak, a possible workaround is to test if the database is locked before executing any database query and bail if it is at the time. But it seems overkill just not to show a non-feature breaking warning on the error log.
