• I recently setup Jetpack statistics on a large website in a hope to receive secondary results to google analytics. We noticed we began having issues with “Error establishing a database connection” messages to both our visitors and ourselves when attempting to access the website during peak times. We narrowed the issue down to myISAM locking up the database when too many update requests came in at the same time. We noticed that in particular Jetpack statistics were trying to “update” the “_transient_random_seed” 28 times per page load…

    UPDATE _options
    SET option_value = ‘b7807df715be9ec082b206a2cbca4561’
    WHERE option_name = ‘_transient_random_seed’

    Is there not a better way to handle this? We had to disable the Jetpack stats on our site… is there something we can do to help minimize this issue?

    Update: We’ve now had this issue on 2 different “largish” websites on 2 different servers.

    Thanks.

    https://ww.wp.xz.cn/plugins/jetpack/

Viewing 3 replies - 1 through 3 (of 3 total)
  • Plugin Author Jeremy Herve

    (@jeherve)

    Jetpack Mechanic 🚀

    Thanks for the report.

    Jetpack uses wp_generate_password, that generates unique numbers to use to create nonces. That’s the request you see in your database.

    That doesn’t explain why this would happen 28 times per page load, though.

    I’ve created a GitHub issue here and we’ll look into the problem and get this fixed. Feel free to subscribe to follow our discussion.

    Could you confirm that you run the latest version of Jetpack and WordPress? What other plugins are currently active on these sites?

    Thanks!

    Thread Starter perdrix

    (@perdrix)

    Hi Jeremy,

    We are running the latest versions of both Jetpack and WordPress. We are not running the latest version of mysql however. Could that be an issue? We are running 5.0.96-community.

    I didn’t actually count the number of times it occurred on the second website. The 28 was the number it occurred on the first site, and once I disabled the stats, I had 0 counts. And it was 28 times on each page, whether the home page or an article.

    In each case, the requests overwhelm the database and then corrupts the table. It requires us to repair the table before the website would operate again. We tried changing the table to InnoDB and while it worked better, it eventually crashed that, and it’s unable to be fixed. So we recreated the table from a backup.

    I will subscribe to the discussion on Github, and would be happy to allow an Automattic employee access to the site in question to see what happens.

    Thread Starter perdrix

    (@perdrix)

    Jeremy, I’ve updated GitHub with the latest information I was able to come up with. Note, that in the interim we have updated to the latest MySQL. Apparently there appears to be a conflict with JetPack stats and MathCapcha that makes the transient update the database where with either one activated by themselves, neither plugin acts in that manner.

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

The topic ‘Jetpack Statistics Causing MySQL errors’ is closed to new replies.