Deadlock found

  • Resolved Jimmy Lee

    (@shirtguy72)


    6 years, 3 months ago

    Hello Gabe, Logged into Siteground today and seen my CPU was being absolutely pounded, I rolled back Assest Cleanup to version 1.3.5.3 and it stopped. Found the following in my public_html/php_errorlog …

    [15-Feb-2020 01:29:26 UTC] WordPress database error Deadlock found when trying to get lock; try restarting transaction for query DELETE FROM ***_***options WHERE option_name = ‘_transient_wpacu_js_optimize_658eaf9e4591d02e195f2bc92f217aae’ made by require(‘wp-blog-header.php’), require_once(‘wp-includes/template-loader.php’), include(‘/themes/metro-magazine/front-page.php’), get_footer, locate_template, load_template, require_once(‘/themes/rara-magazine/footer.php’), wp_footer, do_action(‘wp_footer’), WP_Hook->do_action, WP_Hook->apply_filters, wp_print_footer_scripts, do_action(‘wp_print_footer_scripts’), WP_Hook->do_action, WP_Hook->apply_filters, WpAssetCleanUp\OptimiseAssets\OptimizeJs->prepareOptimizeList, WpAssetCleanUp\OptimiseAssets\OptimizeJs::maybeOptimizeIt, WpAssetCleanUp\OptimiseAssets\OptimizeCommon::deleteTransient, delete_transient, delete_option

Viewing 4 replies - 1 through 4 (of 4 total)
  • Plugin Author Gabe Livan

    (@gabelivan)

    6 years, 3 months ago

    @shirtguy72 Thanks for reporting this! There have been a few tickets about this issue and it’s under investigation. If you had this issue with the latest version of the plugin, you will likely have it with v1.3.5.3 as the code behind it is the same.

    Let me know how it goes, if you’re still getting the errors or not! Sorry about that, really! It doesn’t happen often, but when it does, it’s annoying indeed. In the next version of the plugin, there will be an option to avoid making these queries completely and only read the caching information from the disk.

    Thread Starter Jimmy Lee

    (@shirtguy72)

    6 years, 3 months ago

    Thanks Gabe, no problem glad I could help. Also no worries to keep checking the errorlog as I have ‘DISALLOW_FILE_EDIT’… FILE_MODS’ snippets that need to manually be changed, so I’m in my document root multiple days a day anyway.

    Latest version active the last 48 hrs. Same error displayed once yesterday afternoon.
    Always look forward to Asset Cleanup updates, always GOOD STUFF! Again thanks.

    Plugin Author Gabe Livan

    (@gabelivan)

    6 years, 3 months ago

    @shirtguy72 This deadlock error needs more testing on my end as it does happen once in a while for some users, never happened on my tests or any other server I installed Asset CleanUp on. There’s another storage method which shouldn’t trigger any of these errors since it doesn’t rely on MySQL to store the caching information, but it’s kept on the disk as JSON files. Can you please download the latest version (v1.3.5.7), then go to “Settings” -> “Plugin Usage Preferences” -> “Fetch assets’ caching information from:” and choose “Disk (default)”. Then, after you save the settings, test a few pages and check if you got (after the plugin update) any of the deadlock errors. You shouldn’t get any of them! Let me know how it goes at your earliest convenience!

    Thread Starter Jimmy Lee

    (@shirtguy72)

    6 years, 3 months ago

    Updated, set to disk, so far so good. In the next few days I will monitor the errorlog being mindful of actions I’ve taken on the backend if I get hit with this error again.

    Wordpress Developer Of The Year Award? You’d get my vote! Thanks Gabe.

Viewing 4 replies - 1 through 4 (of 4 total)

The topic ‘Deadlock found’ is closed to new replies.