Skip site navigation (1) Skip section navigation (2)

Re: Recommended/Not Recommended Hosts?

From: Sailesh Krishnamurthy <sailesh(at)gmail(dot)com>
To: Josh Livni <josh(at)umbrellaconsulting(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, SF Postgres <sfpug(at)postgresql(dot)org>
Subject: Re: Recommended/Not Recommended Hosts?
Date: 2009-12-11 23:48:36
Message-ID: (view raw, whole thread or download thread mbox)
Lists: sfpug
Has anyone used EBS on EC2 ?

I/O is supposed to be much better on it


On 12/10/09, Josh Livni <josh(at)umbrellaconsulting(dot)com> wrote:
> Cool, Thanks for the detailed response.  I've certainly not done a ton of
> research comparing different VPS solutions myself,  but I was under the
> (quite possible mis-impression) that at EC2 the underlying hardware was not
> 1:1 related to your performance (eg you get a set amount of cpu throughput,
> and if they had older hardware underneath, then you'd just get more of it).
>  I also did not realize other users could steal cycles from you like happens
> on most other VPS offerings.  I haven't seen that much documentation to base
> any of these assumptions on, of course, so it's good to hear your
> perspective.
> Some posts, such as,
> seem to imply different conclusions (not that he's suggesting EC2 is a good
> deal, but for different reasons than cpu stealing), and I'd love to see
> similar posts on the topic:  I'd be happy to switch to something else if I
> felt I was going to getting a much better deal (I really do like the
> integrated EBS/S3/Cloudfront options tho for the type of projects I
> generally work on).
> Cheers,
>  -Josh
> On Thu, Dec 10, 2009 at 11:20 AM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
>> Josh,
>> > Pure curiosity on my part here ... I use EC2 a bit, tho not as much as
>> > the serious users.  A few large and small instances on all the time, and
>> > I boot up new ones for shorter periods all the time.   First - I've
>> > never had any issue getting my instances fulfilled right away (I always
>> > use EAST-C, but perhaps other datacenters are generally more full, or
>> > you are trying to boot up many tens of servers at once?).
>> Yeah, the two issues I've had are (a) requisitioning high-end instances
>> (like 32G/16core instances) and (b) allocating a lot at once.  Sometimes
>> instances just "aren't available" and there's no way to find out when
>> they will be available.
>> > Also, when you say they are slow, do you mean in terms of $/cycle,
>> > or you wish you had burst access to other users unused cycles like on
>> > some other vps offerings? something else?
>> I mean that if you have an 8core/16GB instance, the actual processing
>> throughput you get is about 1/6 to 1/4 that of a new HP DL380 machine
>> with 8cores and 16GB.  So you really need 4x as many EC2 instances to
>> match bare metal.  Partly this is due to CPU-stealing, and partly to
>> erratic and lag-prone I/O, and partly to the fact that a lot of machines
>> in the EC2 pool are 4 years old.
>> > I like the bundle of offerings that AWS provides (EBS, especially), and
>> > I've personally had great experience w/them (fwiw I've also had great
>> > experience w/slicehost) -- but if I am getting missing out on how
>> > they're screwing me, for example by stealing my CPU, I'd definitely love
>> > to learn more.
>> On EC2, other VMs on the same hardware are permitted to "steal" portions
>> of the CPU which are allocated to you.  So at any given time, you may
>> have as little as 50% of the CPUs you're being billed for.  And, when
>> CPU availability is fluctuating up and down (as it does on EC2), real
>> throughput tends to be based on the slowest second rather than peak
>> availablity.  Most Linux apps, especially databases, do quite poorly
>> with erratic resource availability.
>> --Josh

Sent from my mobile device


In response to


sfpug by date

Next:From: Jason DiCioccioDate: 2009-12-12 00:21:35
Subject: Re: Recommended/Not Recommended Hosts?
Previous:From: Steve AtkinsDate: 2009-12-11 23:18:41
Subject: Re: Recommended/Not Recommended Hosts?

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group