I've used ServerBeach for five years (as well as RackSpace, Slicehost, and Linode). Generally positive experience; they have occasional downtime as you might expect, but it hasn't impacted my sites to any significant degree. Their self-service tools are decent. Good support, good user forums. I'm about to upgrade one of my servers there and plan on using them for the foreseeable future.
I've used them for 4.5 years and have had less downtime than a Rackspace box I've been running for 2 years. Support is good, network is good, prices are good. I'm satisfied with them. Only complaint I have is that they don't lower your rates when the rates get lowered for new customers (non-promo prices) unless you ask.
There are a lot of great prices in Europe (OVH in France, Heitzner in Germany), but not in the US to my knowledge. I've tried to run a server in Germany (Heitzner). The latency + newtwork issues (dropped packets) was not worth the price difference if your audience is in the US.
How did you come to that conclusion? From what I'm seeing, the large instance is $0.34/hour, or $244/month. It looks like for a bit less ($199), one can get a 2x quad-core xeon with 6 gigs memory with the other deal.
moreover, you should expect to pay more for a physical server. It's more expensive to run a physical server than a slice of a virtual (at least until the physical servers start getting bigger than 32 or 64GiB)
Physical servers provide more value to the user, too; if you split a disk to 8 VMs, in times of contention, each vm gets significantly less than 1/8th of the disk's maximum performance. See, sharing the disk means that during times of contention, what would otherwise be sequential access become random access, and disk, especially cheap sata disk, is not any good at random access.
I wrote a bit about it here http://wiki.xen.prgmr.com/xenophilia/2010/03/forward-looking... when I was trying to track down a problem that pinboard was complaining about. (turns out the problem was actually a debian xen bug and not actually the problem I was describing. But what I say above is still true; virtualization is not any good at all for disk I/O)
Not meant to be, I just thought this was an unusually low price and was considering biting. I posted it partly to share with everyone else here running an internet business, partly to get a potential reality check from the comments, and to see if anyone had disparaging things to say about ServerBeach.
True on both counts, though they offer RAID for a fee (40-100/mo for controller, then drives). Instead I'm planning on going SSD for 60/mo more + aggressive backups (bad idea?)
I'm planning on using this for things where performance matters a lot more than 100% data integrity.
SSD is not raid. get a second drive; you should be able to setup software raid without their help, and for a mirror, there shouldn't be much performance difference between software and hardware raid.
ECC ram is a larger problem, at least in my mind. having wrong data without knowing it is about the worst thing possible. ECC at least has the courtesy to crash my box when it gets an error it can't correct.
My rationale is that random small block read/write perf of a single SSD is greater than that of RAID 0 of traditional disks, so I was going to go that route. If I notice that there's still an IO bottleneck, I'll consider adding another.
Oops I seem to have misread this comment... you did say "mirror".
As for ECC, how often does corruption occur? 100% Data integrity is not hugely important for the main app that will be sitting on this box, so a cosmic ray here or there isn't a big deal, but persistent unknown errors would be a problem.
if the ram is good ahead of time, bit flips are pretty rare. I mean, not unheard of, but if you are storing a bunch of mpegs, or tweets or what have you, it doesn't matter that much. when your ram goes bad, you will have lots of random crashes (and at that point, boy howdy, any data that was written gets screwed royally. You are really best off loading from backup at that point, on a new box.)
That is the other problem; because it's not 100% clear it's the ram (without ecc) it's easy for the service provider to push around 'half bad' modules without really fixing them. I know at all the big places I've worked, it was an incredible pain to get people to take a hardware problem seriously enough to get them to let me fix it, rather than just re-imaging the box and putting it back on the 'available box' queue.
there is no substitute for memtest86. but without a KVM over IP (or flipping a bit in memtest86 and a serial console) that's pretty useless to you.
At one point I had a set of patches to memtest86 that made screen scraping the pass/fail off a serial console much easier for one of the larger companies I worked for. But it'd be serverbeach that would need to implement that, and very few dedicated server providers give you serial consoles.
I did at one point, but it doesn't look like it makes sense for me to host dedicated servers for less than super premium prices, and frankly, I don't feel like providing the level of support that would be expected with such pricing.
Nice, it looks like I can get 2x1TB drives (gotta have my software raid) and 8GiB ram for around $250/month with that code. nice. (I mean, it's still cheaper to own, and obviously, I'm equipped to deal with my own hardware, but that's a relatively reasonable price as far as renting hardware goes.)
21 comments
[ 4.0 ms ] story [ 61.4 ms ] thread49€/month for a Q6600 quad-core.
and 99€ for a octo-core and 12gigs of ram.
I'm using their quad core at the moment for 6 months and nothing bad happened. Didn't try their tech support, though.
Physical servers provide more value to the user, too; if you split a disk to 8 VMs, in times of contention, each vm gets significantly less than 1/8th of the disk's maximum performance. See, sharing the disk means that during times of contention, what would otherwise be sequential access become random access, and disk, especially cheap sata disk, is not any good at random access.
I wrote a bit about it here http://wiki.xen.prgmr.com/xenophilia/2010/03/forward-looking... when I was trying to track down a problem that pinboard was complaining about. (turns out the problem was actually a debian xen bug and not actually the problem I was describing. But what I say above is still true; virtualization is not any good at all for disk I/O)
I'm planning on using this for things where performance matters a lot more than 100% data integrity.
ECC ram is a larger problem, at least in my mind. having wrong data without knowing it is about the worst thing possible. ECC at least has the courtesy to crash my box when it gets an error it can't correct.
As for ECC, how often does corruption occur? 100% Data integrity is not hugely important for the main app that will be sitting on this box, so a cosmic ray here or there isn't a big deal, but persistent unknown errors would be a problem.
That is the other problem; because it's not 100% clear it's the ram (without ecc) it's easy for the service provider to push around 'half bad' modules without really fixing them. I know at all the big places I've worked, it was an incredible pain to get people to take a hardware problem seriously enough to get them to let me fix it, rather than just re-imaging the box and putting it back on the 'available box' queue.
I'll kick the tires before I switch everything over. Know of any good memory tests? :-)
At one point I had a set of patches to memtest86 that made screen scraping the pass/fail off a serial console much easier for one of the larger companies I worked for. But it'd be serverbeach that would need to implement that, and very few dedicated server providers give you serial consoles.
I did at one point, but it doesn't look like it makes sense for me to host dedicated servers for less than super premium prices, and frankly, I don't feel like providing the level of support that would be expected with such pricing.