Very recently, I began experiencing very slow load times, latency and hundreds of downtimes and on this blog and on HandmadeCloud both of which run on WordPress and are hosted with MediaTemple. The problems reached critical mass when I received an email from MediaTemple stating that:
Subject – Your Databases Have Been Auto-Scaled
(mt) Media Temple’s automated MySQL monitoring systems have detected an increase in database activity for your Grid-Service (jessicadoyle.com). Your databases are now being served from a MySQL Burst Container to help your web applications scale during this surge in activity. These containers are a component of our MySQL SmartPool v.2 that allows your websites to instantly handle intense, temporary bursts of database activity.
And the email goes on to explain in further detail and ends with a short Q&A.
About an hour before receiving this email I noticed my uptime on Pingdom was awful for HandmadeCloud and then the site wasn’t loading at all. Then the auto-scale email came. I panicked and began frantically watching a customary search that I perform on Twitter to see if other MT customers were being effected with this, began contacting alternative hosts, posted in the MT support forums and opened a support request.
Things hit critical mass when MT suspended my account moments after giving my sites the extra juice they needed to keep going. I was dumbfounded and couldn’t understand how my sites were using so much *GPU when I was only receiving an average 500 to 900 visitors per day to both sites combined and was not bursted back in April 2010 when this blog was featured in an Etsy Finds email on the Etsy blog. During that six day period this blog received a whopping 20,000 visitors and it was not bursted into a container.
I began thinking there was someone at MT who had it out for me. I was flabbergasted and began tweeting to get the support ticket answered quickly. My account was reinstated with a nice apology and a one month’s credit toward hosting cost, saying that the suspension was done in error. I couldn’t understand how this happened in the first place and continued to write back in the MT support queue.
About an hour later Miguel P., senior tech support phoned me. I answered. He said Hi. I said Hi. The phone call was very unexpected. My nerves calmed. We talked for about 30 minutes.
Miguel pointed out on the phone that the database for JessicaDoyle.com was too large coming in at 38MB. I contacted my friend Andrew Park with my research on the aforementioned issues and he helped me to feel confident enough to dive in WP-DBmanager (which I had installed months ago) and with PHPmyadmin. After a few tense moments of creating way too many database users, bringing HandmadeCloud to it’s knees, editing wp_config.php and then learning the difference between dropping a table and emptying it, I began deleting database files, that WordPress plugins that I had installed over the last 18 months had created, without my knowledge.
I was vaguely aware that a plugin could do this after having a fiasco of a time attempting to uninstall and remove the WP E-commerce plugin for WordPress in late 2009. There isn’t much info online regarding the removal of databases that are created with WordPress plugins. This fact alone is infuriating and I suspect that hundreds of thousands of WordPress users are experiencing the same hosting issues that I am without knowing the cause of their site’s inconsistent load times, time-outs, downtimes and database errors.
WordPress plugin developers, you need to list and inform potential WordPress users of any databases that are created with your plugins and the proper instructions on how to remove them if the user decides not to continue using your plugin! Because simply uninstalling or deactivating the plugin does nothing to remove the databases it created. This should be a rule instated within the WordPress plugin directory. Really.
The plugin that caused so much of my grief is WP-Lifestream. On the outside it looks like a nice tidy plugin to import all your social feeds into one place to display them on one page or within your blogs sidebar. This plugin is barely supported by it’s author! There is nothing anywhere online telling how to remove the databases it creates or that databases are created in the first place, once installed and that it will cause wp_cron.php to incessantly fire even if it’s not being used or populated with social media content.
I removed four top level files that it created within the database. However, upon further research within the wp_posts database which as pointed out by Miguel P. earlier that day was huge at a whopping 50,000 plus entries, I learned that WP-lifestream had populated that table with over 40,000 empty rogue entries!
Another culprit and database hog is WP-Popular-Posts. But before I remove the top level files associated with this plugin I need to confirm with someone in the know if they have anything to do with the core functionality of WordPress. This is proving impossible to.
After research I was able to locate what the core WordPress database files are. I was able to find others that were experiencing the same issue with WP-Lifetream but were finding no solution and likely weren’t aware of why Lifestream was placing such a heavy load on their databases.
I checked my GPU stats today. And ss soon as I removed the Lifestream top level files my usage returned to normal and wp_cron.php is no longer firing at all!
To make a long story short… that one phone call and the follow up support with MT gave me the confidence to begin diving into MySQL to find the problem on my own. And I suspect that thousands of other people on MT and other hosts are experiencing the same issues. This is sad and even sadder that it’s not the host’s problem but the end user’s problem; the customer not understanding how advanced WordPress and the WordPress plugins that you install, really are.
A little bit of encouragement and explanation from a host goes a long way in calming customers. And that is exactly what Miguel from MT did. I really had no idea what was happening… and finally someone took the time to say “Hey, it’s your database. We can’t fix it but you may want to look at it and also look into a caching plugin such as… And there may be a plugin causing the database problems.” I really had no idea in the beginning… that this was what was causing the some of issues and did my best to resolve them.
*MT allots 1000 Grid Performance Units (GPU) per month per Grid Server (GS) account and I used almost 700 GPU this month.