Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

"Amazon's EBSs are a barrel of laughs in terms of performance and reliability"

reddit.com

Post reply on HN
Print view View original

51–60 of 157 posts

Re: "Amazon's EBSs are a barrel of laughs in terms of performance and reliability"

#51

Post by xpaulbettsx »

bluegene wrote: post #35
rlpb wrote: post #26

RAIDing together multiple EBS volumes feels like a massive hack to me. I can't help but wonder if this compounds the problem at Amazon's end. If EBS performance is a problem, Amazon need to fix it. For example, if some way of tying together multiple EBS volumes is a reasonable way of working around the problem, then why aren't Amazon providing "high performance" EBS volumes which do that under the hood? If I were fac…

May be I'm missing something here; Why there's even a discussion about RAID at the EBS level? When Amamzon says, "Amazon EBS volumes are designed to be highly available and reliable" and if we have to talk about RAID then the issue is on Amazon's end

I think most people are doing RAID-0 to get more perf out of EBS volumes

Re: "Amazon's EBSs are a barrel of laughs in terms of performance and reliability"

#52

Post by saurik »

andrewvc wrote: post #27
rlpb wrote: post #26

RAIDing together multiple EBS volumes feels like a massive hack to me. I can't help but wonder if this compounds the problem at Amazon's end. If EBS performance is a problem, Amazon need to fix it. For example, if some way of tying together multiple EBS volumes is a reasonable way of working around the problem, then why aren't Amazon providing "high performance" EBS volumes which do that under the hood? If I were fac…

One other huge downside of raiding EBS volumes is you can't use EBS's snapshotting features as you cannot guarantee a perfect sync (you could use LVM yourself however). Honestly, since EBS vols are supposedly not tied to a single disk, the raiding should be done on Amazon's end. That it isn't is telling.

You have to snapshot at the system level anyway if you want a consistent snapshot: otherwise the filesystem (or your database) could have been reordering and delaying writes that end up not being part of the "consistent snapshot". This is simply not a RAID-specific issue, nor is it a problem with EBS (as it is generally easy to use LVM, xfs, and/or PostgreSQL to handle that part of the job).

Re: "Amazon's EBSs are a barrel of laughs in terms of performance and reliability"

#53

Post by grourk »

joevandyk wrote: post #46
mithaler wrote: post #10

We were bitten by EBS' slowness at my company recently, when moving an existing project to AWS. You effectively can't get decent performance off of a single EBS volume with PostgreSQL; you need to set up 10 or so of them and make a software RAID to remove the bottleneck. It's a fairly large time commitment to build and maintain, but it's pretty fast and reliable once it's up and running (cases like the recent downtim…

Did you use Raid10? I would love to see a post on using postgresql with ec2/ebs -- how to setup raid, etc.

Orion Henry at Heroku wrote about this and described different software RAID configurations and the performance characteristics of each a while back:

http://orion.heroku.com/past/2009/7/29/io_performance_on_ebs...

Re: "Amazon's EBSs are a barrel of laughs in terms of performance and reliability"

#54

Post by saurik »

mithaler wrote: post #10

We were bitten by EBS' slowness at my company recently, when moving an existing project to AWS. You effectively can't get decent performance off of a single EBS volume with PostgreSQL; you need to set up 10 or so of them and make a software RAID to remove the bottleneck. It's a fairly large time commitment to build and maintain, but it's pretty fast and reliable once it's up and running (cases like the recent downtim…

Did you do any performance tweaking to PostgreSQL with respect to EBS? You have an insanely deep write buffer and quite good random read performance with EBS, which is nothing like the disks people normally deploy PostgreSQL to.

Re: "Amazon's EBSs are a barrel of laughs in terms of performance and reliability"

#55

Post by acdha »

rlpb wrote: post #26

RAIDing together multiple EBS volumes feels like a massive hack to me. I can't help but wonder if this compounds the problem at Amazon's end. If EBS performance is a problem, Amazon need to fix it. For example, if some way of tying together multiple EBS volumes is a reasonable way of working around the problem, then why aren't Amazon providing "high performance" EBS volumes which do that under the hood? If I were fac…

I wish I had more than one upvote for this: swimming against a trend like that never works out well.

Re: "Amazon's EBSs are a barrel of laughs in terms of performance and reliability"

#57

Post by watchandwait »

jameskilton wrote: post #6

This comment further down, supposedly from an Amazon employee, paints a grim picture for EBS: http://www.reddit.com/r/blog/comments/g66f0/why_reddit_was_d...

This comment does not seem legitimate. There's nothing in it that would imply special knowledge of AWS or EBS.

Re: "Amazon's EBSs are a barrel of laughs in terms of performance and reliability"

#58

Post by saurik »

hemancuso wrote: post #38

I've never understood how people can use EBS in production. The durability numbers they quote are bad and they wave their hands around about increased durability with snapshots, but never quantify what that means. Hard drives are unreliable and they certainly don't fail independently of one another - but the independence of their failure is much more independent than EBS. With physical dives and n-parity RAID you dra…

The increased durability based on snapshots is actually quite simple, and they explain it in various places: if one of the drives in Amazon's RAID fails, they need to bring up a new disk to replace it in the array. When they being up new disks they typically can do this instantaneously, because they really just dynamically page fault the drive from your latest snapshot. However, all dirty data since the last snapshot will have to be copied from the other drive(s). This is a window of time during which your array is exposed to unrecoverable read errors losing data. The less dirty data you have, the smaller this window of time.

Re: "Amazon's EBSs are a barrel of laughs in terms of performance and reliability"

#59

Post by watchandwait »

snorkel wrote: post #43

Having been at a startup that used hundreds of EC2 instances and EBS volumes I can assure you all that Amazon EBS performance is downright terrible and Amazon didn't inspire any confidence that they could solve it. Even worse than the EBS performance is Amazon does not offer any shared storage solutions between EC2 instances. You have to cobble together your own shared storage using NFS and EBS volumes making it suck…

My experience with the AWS RDS database product has been excellent.

Re: "Amazon's EBSs are a barrel of laughs in terms of performance and reliability"

#60

Post by romaniv »

jedsmith wrote: post #30
ck2 wrote: post #24

I firmly believe "the cloud" is a fad, unless for some reason you own and operate all the hardware yourself (ie. Google). Like other technical fads, everyone will probably come back to servers they can reach out and touch when needed, sooner or later.

The cloud significantly lowers capital expenditure to get into an Internet-enabled business, which cultivates the very startup ecology that Y Combinator exists to leverage and support. Those teenagers who started the Facebook Pokemon game would have never had the resources to build a scalable solution with hardware that they own. (That is, unless Y Combinator paid a lot more money as part of participating. They might…

You can do a lot of the things you describe here with VPS (Virtual Private Servers). You get root access, you don't manage hardware, you often receive some virtualization benefits (images, snapshots). Does that count as "Cloud Computing"?
Post reply on HN