For extra points do serious burn-ins, especially on network hardware, keep a good eye on those error counters as well as mcelog in case you got a faulty ram in there.
It's all part of commissioning a server, especially if you host at a cheap outlet like rackspace.
I've heard rackspace called lots of things, but this is the first time I've heard someone call them "cheap". Have their prices gone down lately?
This happened to me several times at EV1, same with memory and CPU.
It really pays off to check if you can boot a machine with an SMP kernel and another CPU shows up too (don't bother doing that on a celeron box though).
If in two years time you've never ever had a look at what kernel you are running, especially while tuning a system for performance you only have yourself to blame.
Don't tell me you're running a 'stock' kernel and never bothered tuning it for your application, or considered upgrading it. Also, in your resources list you should have the exact machine configuration, there are tools to retrieve that sort of info automatically.
Then, when you're done, store it in http://inventory.sf.net/ or something like that.
It's typical that the people at rackspace would simply drop in the requested hardware, and that you yourself deal with the configuration.
The smart money is on running some tests after they've done that to make sure it went ok. Asking for a CPU upgrade and not checking if they're operational is just plain stupid.
I figure you literally asked rackspace to upgrade the CPU, and that's what they did.
Did you explicitly ask them to install an SMP kernel with a specific version and they didn't do it ? Or did you expect them to do it but you didn't check if they actually did until today ?
Two full years of trying to tune a box for performance and not noticing this, then publicly blaming rackspace is simply cheap, an attempt at pinning the blame on rackspace, for something that you should have noticed long ago yourself.
Kudos for writing about it but the title should be "How I messed up". That's taking responsibility and then make sure it never ever happens again.
If you're using "spidey-sense" to determine the underperforming elements in your software stack...
There are a number of uncomfortable ideas in this article.
I noticed a similar gain (10-12 req/s to 25-30req/s) for action cached pages after switching out nginx+passenger for nginx+thin. This is on a 256mb slice, and seems totally counter to the general opinion that passenger is great for VPSes.
