My Plan 'B' Is To Complete Plan 'A'

This Is a t1.Micro Server ...

... an this is a t1.micro server running WordPress:

CentOS Top | WordPress CPU Usage

Any questions?

There are undoubtedly a billion questions, like "How the heck can MySQL be consuming 100% CPU?" or "how many people are connecting to the server right now?" or "How the heck can so many processes be consuming so much CPU on Amazon's smallest virtual server?". These are all questions that I've been struggling with while trying to determine just what the heck has changed between WordPress 3.1.0 and 3.1.1.

I've been using one of Amazon's Free Tier servers to host this blog and, for the most part, it's been working out pretty well. Amazon allows new subscribers to use a "free" t1.micro server for 750 hours with limited amounts of space and bandwidth in order to test drive their services. As I manage the Amazon servers for my employer, I've come to know what one can expect from various server sizes. That said, there are sometimes some problems.

In this case, I had recently updated WordPress from 3.1.0 to 3.1.1. There were some hiccups with two plugins, so I disabled W3 Total Cache, disabled and re-enabled all of the plugins, restarted Apache, flushed the cached files, re-enabled W3 Total Cache. Everything was working wonderfully ... until I hit "Publish" to send out a new post.

The Twitter plugins sent out the notification that a new post was available just fine. The cached pages were created just fine. The notifications of an update were about to be sent to the various servers when MySQL started to stutter under an increased load. Apache was also busy as heck, occasionally running with as many as 50 threads. Had one of my previous posts suddenly gone viral and W3 wasn't kicking in? Was Memcached or some other package that has been installed for months all of a sudden sucking up all the resources and interfering with the server?

From what I can tell ... it was none of these things. Instead, it's likely that something has changed inside WordPress that resulted in this increased load and I'll have to investigate further.

Fun? Wow!

Page generated in roughly: 0.527215 Seconds, 0 API Calls, 6 SQL Queries, 9 Cache Objects