_site_transient_wpmudev_updates_data in Options table currupt?

I've had this happen on a couple of other sites before as I was moving them from one hosting account to another, but today it really impacted one of my clients badly where the site had been in place on the new hosting system for two months. From what I can see, it seems the _site_transient_wpmudev_updates_data entry in the Options table is somehow causing some corruption that kicks off the mysql repair process and hangs the database so that all new requests hang until the server memory is exhausted and Apache crashes. This happened on a site that happened to be experiencing higher utilization (500+ page views today, which probably would have been closer to 1,000+ if not for the outages). The contents of the entry are over 300,000 bytes long. I don't know if it's a problem because of the size or what, but my solution was to do the following:
1) Disable the WPMU Dashboard Plugin
2) Delete the row
3) Successfully ran a repair

The problem was recurring every hour on the hour (more or less). When it occurred, the only solution I have (since I am using a managed VPS at A2Hosting) is to reboot the VPS... clearly if I had actual root privileges to the VPS, a recycle of the MySQL daemon would likely be adequate... regardless, it is highly impactful.

It looked like this row is used by the hidden Update plugin, but I have not investigated any further.

There may actually be something else I'm missing here, but the action list I provided above did solve the problem.

In case it matters, the table in question is using the MyISAM engine.

If needed, I have a dump of the row in question.


Art Smith
Ambrosia Web Technology, LLC

  • Ambrosia Web Technology

    Oh, and here are the versions in use:

    WordPress: 3.7.1 (upgrading in a few weeks... had delayed due to testing and getting past the annual show event that the site is built for)
    WPMU Dashboard: 3.4 (also upgrading in a few weeks... we generally update software on a monthly basis)

    Also, following are all of the installed plugins and versions:

    Advanced Access Manager Version 1.9.1 |
    AMB_Functions Version 0.5 (custom plugin written by Art, miscellaneous functions)
    BackupBuddy Version
    BlogRoll Loader Version .1 (Custom plugin written by Art, loads csv file to the Links table, currently disabled)
    Core Control Version 1.1
    Display widgets Version 1.24
    Select Easy Theme and Plugin Upgrades Version 1.0.2
    Exploit Scanner Version 1.3.3 (Disabled)
    Google Analyticator Version 6.4.5
    Gravity Forms Version 1.7.12
    INEDA Custom Code Version .1 (Custom plugin written by Art, includes some service processes for special pages)
    INEDA Custom Tables Version .2 (Custom plugin written by Art, for additional table customizations)
    MapPress Easy Google Maps Version 2.40.7 |
    MiniMeta Widget Version 4.5.3
    Mobile Website Builder for WordPress by DudaMobile Version 1.0.3
    Print me! Version 0.4.2 (Disabled)
    Query Posts Version 0.3.2 (Disabled)
    Real Time Twitter Version 1.0.2
    Redirection Version 2.3.4
    Rotating Images Version 1.2.7
    Rotating Text Version 1.0.32
    Simple Login Redirect Version 1.12
    Ultimate Branding Version 1.5.5
    Ultimate Maintenance Mode Version 1.5.3
    Ultimate TinyMCE Version 5.1
    URL Params Version 1.5
    User Switching Version 0.8.4
    W3 Total Cache Version 0.9.3
    WD Twitter Feed Version 1.2.1
    Wordfence Security Version 3.8.9
    WordPress SEO Version 1.4.19
    WPMU DEV Dashboard Version 3.4 (Disabled)
    WPMU DEV Videos Version 1.2.4
    WP Robots Txt Version 1.1

  • Aaron

    Hi There, I've heard of corruption or encoding issues with the serialized array, but not with the actual table.

    I'm not familiar with what would trigger an automatic repair. I guess the –myisam-recover.

    I have no ideas what might cause this, how did you determine that it was with that specific row that triggered the corruption?

    Something you could try on that server is changing the table to innodb.

  • Ambrosia Web Technology

    The first time it happened in late November / early December, as I was moving my sites from HostGator to A2Hosting. Right after importing with BackupBuddy, I needed to do an upgrade on some sites to WP 3.7.1. During the upgrade, everything got hung up, but then seemed to be updated okay. A day or two later my server ran out of memory because of one of the sites getting stuck during a WP_Cron event that was happening at about the same time each day. I eventually figured out by manually running a repair on individual tables that it was the options table that was in trouble. I looked at the dump of the table from my site move, and I noticed that the row in question was very very large compared to everything else in the table, but I wasn't convinced that was the issue right away. Eventually, I isolated the cron event to the twice daily "wpmudev_scheduled_jobs" (not sure why it only happened once a day), and that led me to the conclusion that the transient data entry must be causing some kind of corruption. At that time, I merely deleted the entry and the problem went away. I chalked it up to something wonky with the process of moving from HostGator to A2Hosting. Then I had this problem out of the blue a few weeks ago and I knew where to look first. The hourly impact I think is due to some other cron process simply touching the table, but the solution I outlined in my original posting did work. I will concede that it is possible there may be something else at play here, but I am at a loss as to what it is unless it is something timing related... this being over 300K of data in one row, although out of the norm, doesn't typically cause me concern. I will proceed with switching to the innoDB engine for the table and see if that changes anything. I hope you don't mind if we keep the issue open for a few days while I watch and see what happens.

    I do appreciate the help with this!!!



Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.