Cat /proc/cpuinfo or don't trust your cores to rackspace part i
1–10 of 34 posts
Re: Cat /proc/cpuinfo or don't trust your cores to rackspace part i
#2If you never run top '1' then you shouldn't be operating servers for customers.
Re: Cat /proc/cpuinfo or don't trust your cores to rackspace part i
#3After the conversion from Apache [+passenger] to Nginx [+unicorn] overall throughput went up by a factor of 3.
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.
Re: Cat /proc/cpuinfo or don't trust your cores to rackspace part i
#4After the conversion from Apache [+passenger] to Nginx [+unicorn] overall throughput went up by a factor of 3. 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.
Have you tried nginx/passenger? I ask because I wonder how much of that gain is part of switching to nginx rather than switching to unicorn...
Re: Cat /proc/cpuinfo or don't trust your cores to rackspace part i
#5After the conversion from Apache [+passenger] to Nginx [+unicorn] overall throughput went up by a factor of 3. 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.
Have you tried nginx/passenger? I ask because I wonder how much of that gain is part of switching to nginx rather than switching to unicorn...
on a separate application and server, yes, and it seems faster than apache/passenger, but it still suffers from the 'passenger choke' where touching tmp/restart.txt seems to pause all web traffic for 10-15 seconds, so we never considered it here...
Re: Cat /proc/cpuinfo or don't trust your cores to rackspace part i
#6If you never run top '1' then you shouldn't be operating servers for customers.
attempting to ignore snarkyness, but failing - and that says what about the dozens of rackspace engineers configuring and monitoring and supporting the box over the past two years?
Re: Cat /proc/cpuinfo or don't trust your cores to rackspace part i
#7Don't trust any servers to anyone. When we get a new server we check its stats against reality (have had upside and downside surprises on CPUs), run bonnie++ to make sure IO is as expected (it hasn't been due to exotic RAID problems), and run memtester to see if we have bad RAM (had that too). Takes more time, sure, but no surprises later.
Re: Cat /proc/cpuinfo or don't trust your cores to rackspace part i
#8If you never run top '1' then you shouldn't be operating servers for customers.
attempting to ignore snarkyness, but failing - and that says what about the dozens of rackspace engineers configuring and monitoring and supporting the box over the past two years?
There once was a really nice quote here on HN: "you can't outsource responsibility".
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.
Re: Cat /proc/cpuinfo or don't trust your cores to rackspace part i
#9Don't trust any servers to anyone. When we get a new server we check its stats against reality (have had upside and downside surprises on CPUs), run bonnie++ to make sure IO is as expected (it hasn't been due to exotic RAID problems), and run memtester to see if we have bad RAM (had that too). Takes more time, sure, but no surprises later.
That's the right attitude.
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.
Re: Cat /proc/cpuinfo or don't trust your cores to rackspace part i
#10Don't trust any servers to anyone. When we get a new server we check its stats against reality (have had upside and downside surprises on CPUs), run bonnie++ to make sure IO is as expected (it hasn't been due to exotic RAID problems), and run memtester to see if we have bad RAM (had that too). Takes more time, sure, but no surprises later.
That's the right attitude. 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.
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?