Amazon High I/O instances
Hello,
Since Amazon has added new high I/O instance types and EBS volumes, anyone
has done some benchmark of PostgreSQL on them ?
http://perspectives.mvdirona.com/2012/07/20/IOPerformanceNoLongerSucksInTheCloud.aspx
http://perspectives.mvdirona.com/2012/08/01/EBSProvisionedIOPSOptimizedInstanceTypes.aspx
http://aws.typepad.com/aws/2012/08/fast-forward-provisioned-iops-ebs.html
I will be testing my app soon, but was curious to know if others have done
some tests so I can compare / have a rough idea to what to expect. Looking
on Google, I found an article about MySQL (
http://palominodb.com/blog/2012/07/24/palomino-evaluates-amazon%E2%80%99s-new-high-io-ssd-instances),
but nothing about PostgresSQL.
Thanks !
Sébastien
Le mardi 21 aoᅵt 2012 ᅵ 01:33 -0400, Sᅵbastien Lorion a ᅵcrit :
Since Amazon has added new high I/O instance types and EBS volumes,
anyone has done some benchmark of PostgreSQL on them ?
I wonder : is there a reason why you have to go through the complexity
of such a setup, rather than simply use bare metal and get good
performance with simplicity?
For instance, the dedibox I use for my app (visible in sig) costs 14,00
euros/month, and sits at .03% load average with 5 active users; you can
admin it like a home pc.
--
Vincent Veyron
http://marica.fr/
Gestion informatique des sinistres d'assurances et des dossiers contentieux pour le service juridique
Le mardi 21 aoᅵt 2012 ᅵ 01:33 -0400, Sᅵbastien Lorion a ᅵcrit :
Since Amazon has added new high I/O instance types and EBS volumes,
anyone has done some benchmark of PostgreSQL on them ?
I wonder : is there a reason why you have to go through the complexity
of such a setup, rather than simply use bare metal and get good
performance with simplicity?
For instance, the dedibox I use for my app (visible in sig) costs 14,00
euros/month, and sits at .03% load average with 5 active users; you can
admin it like a home pc.
--
Vincent Veyron
http://marica.fr/
Gestion informatique des sinistres d'assurances et des dossiers contentieux pour le service juridique
On 21 Aug 2012, at 13:32, Vincent Veyron <vv.lists@wanadoo.fr> wrote:
Since Amazon has added new high I/O instance types and EBS volumes,
anyone has done some benchmark of PostgreSQL on them ?I wonder : is there a reason why you have to go through the complexity
of such a setup, rather than simply use bare metal and get good
performance with simplicity?For instance, the dedibox I use for my app (visible in sig) costs 14,00
euros/month, and sits at .03% load average with 5 active users; you can
admin it like a home pc.
This is a general 'cloud or dedicated' question, I won't go into it but I believe cloud proponents cite management ease, scalability etc. I'm sure there's a place for every type of hosting. However I would be interested in hearing some experiences of PostgreSQL on an Amazon high I/O instance, given a client has just proposed running on one. If there are none forthcoming in the short term I may be in a position to provide some results myself in a month or two.
Oliver Kohll
www.agilebase.co.uk
Import Notes
Reply to msg id not found: E1T3nde-0006Vg-4M@malur.postgresql.orgReference msg id not found: E1T3nde-0006Vg-4M@malur.postgresql.org | Resolved by subject fallback
On 8/21/2012 7:10 AM, Oliver Kohll - Mailing Lists wrote:
This is a general 'cloud or dedicated' question, I won't go into it
but I believe cloud proponents cite management ease, scalability etc.
I'm sure there's a place for every type of hosting. However I would be
interested in hearing some experiences of PostgreSQL on an Amazon high
I/O instance, given a client has just proposed running on one. If
there are none forthcoming in the short term I may be in a position to
provide some results myself in a month or two.
Amazon don't say what vendor's SSDs they are using, which is a little
worrying to me -- when we deployed our SSD-based machines last year,
much work was done to address the risk of write endurance problems. Now,
an AWS instance and its ephemeral storage isn't expected to live forever
(keep that in mind when storing data on one!)
so perhaps one can ignore write endurance as a concern in this case
since we'd already be worried about (and have a plan to address) "entire
machine endurance".
For sure performance on these instances for any I/O limited application
is going to be great.
I have a friend who is looking at them for his "big data" analytics
application which spends most of its time sorting Tb sized files.
On 8/21/2012 2:18 AM, Vincent Veyron wrote:
I wonder : is there a reason why you have to go through the complexity
of such a setup, rather than simply use bare metal and get good
performance with simplicity?
In general I agree -- it is much (much!) cheaper to buy tin and deploy
yourself vs any of the current cloud services.
However, there are plenty of counterexample use cases : for example what
if you want one of these machines for a week only?
Another one : what if you are a venture capitalist funding 10 companies
with questionable business models where you expect only one to succeed?
AWS saves you from the headache of selling 500 machines on eBay...
On Tue, Aug 21, 2012 at 12:33 AM, Sébastien Lorion
<sl@thestrangefactory.com> wrote:
Hello,
Since Amazon has added new high I/O instance types and EBS volumes, anyone
has done some benchmark of PostgreSQL on them ?http://perspectives.mvdirona.com/2012/07/20/IOPerformanceNoLongerSucksInTheCloud.aspx
http://perspectives.mvdirona.com/2012/08/01/EBSProvisionedIOPSOptimizedInstanceTypes.aspx
http://aws.typepad.com/aws/2012/08/fast-forward-provisioned-iops-ebs.htmlI will be testing my app soon, but was curious to know if others have done
some tests so I can compare / have a rough idea to what to expect. Looking
on Google, I found an article about MySQL
(http://palominodb.com/blog/2012/07/24/palomino-evaluates-amazon%E2%80%99s-new-high-io-ssd-instances),
but nothing about PostgresSQL.
here's a datapoint, stock config:
pgbench -i -s 500
pgbench -c 16 -T 60
number of transactions actually processed: 418012
tps = 6962.607292 (including connections establishing)
tps = 6973.154593 (excluding connections establishing)
not too shabby. this was run by a friend who is evaluating high i/o
instances for their high load db servers. we didn't have time to
kick off a high scale read only test unfortunately.
Regarding 'AWS vs bare metal', I think high i/o instances full a huge
niche in their lineup. Dollar for dollar, I'm coming around to the
point of view that dealing with aws is a cheaper/more effective
solution than renting out space from a data center or (even worse)
running your own data center unless you're very large or have other
special requirements. Historically the problem with AWS is that you
had no solution for highly transaction bound systems which forced you
to split your environment which ruined most of the benefit, and they
fixed that.
merlin
Le mardi 21 aoᅵt 2012 ᅵ 09:36 -0500, Merlin Moncure a ᅵcrit :
here's a datapoint, stock config:
pgbench -i -s 500
pgbench -c 16 -T 60
number of transactions actually processed: 418012
tps = 6962.607292 (including connections establishing)
tps = 6973.154593 (excluding connections establishing)not too shabby. this was run by a friend who is evaluating high i/o
instances for their high load db servers. we didn't have time to
kick off a high scale read only test unfortunately.Regarding 'AWS vs bare metal', I think high i/o instances full a huge
niche in their lineup. Dollar for dollar, I'm coming around to the
point of view that dealing with aws is a cheaper/more effective
solution than renting out space from a data center or (even worse)
running your own data center unless you're very large or have other
special requirements. Historically the problem with AWS is that you
had no solution for highly transaction bound systems which forced you
to split your environment which ruined most of the benefit, and they
fixed that.
Hi Merlin,
I am sure you can get good performance with these.
I simply focused on the part where seb said he was testing his app, and
since you can get some really high data throughput (by my very modest
standards anyway) with a good machine, I wondered why he did it.
Maybe seb is planning for an application that already has hundreds of
users after all, I did oversee that option.
To Sᅵbastien : please use 'reply all' to send your reply to the list
Le mardi 21 aoᅵt 2012 ᅵ 10:29 -0400, Sᅵbastien Lorion a ᅵcrit :
Could you elaborate on the complexity you mention ? Setting up a machine
on Amazon, even with a script, is quite simple. As for the pricing you
give, it can be matched on Amazon using Micro or small instances, which
would be adequate given your load average.
Well, it _has_ to be more complicated to use AWS than a bare machine,
because of the added layer?
--
Vincent Veyron
http://vincentveyron.com/
Gestion informatique des sinistres d'assurances et des dossiers contentieux pour le service juridique
Oops sorry, I thought I did hit reply all.
I am not sure this mailing list is the right place to have this debate
(assuming it is needed, there are plenty of articles stating the benefits
of using the cloud), so I will simply answer that you pay the cost of the
added layer up front (mostly scripting the Amazon API and batch
configuration), but it saves you a ton of time even in the short term and
even for a 2-3 machines setup. Besides, launching and shutting down 10's or
100's of new instances of a server to answer a burst of requests is hardly
feasible on dedicated hardware, nor is it cheap to rent servers in
different physical locations with some respectable SLA.
Sébastien
On Tue, Aug 21, 2012 at 1:16 PM, Vincent Veyron <vv.lists@wanadoo.fr> wrote:
Show quoted text
Le mardi 21 août 2012 à 09:36 -0500, Merlin Moncure a écrit :
here's a datapoint, stock config:
pgbench -i -s 500
pgbench -c 16 -T 60
number of transactions actually processed: 418012
tps = 6962.607292 (including connections establishing)
tps = 6973.154593 (excluding connections establishing)not too shabby. this was run by a friend who is evaluating high i/o
instances for their high load db servers. we didn't have time to
kick off a high scale read only test unfortunately.Regarding 'AWS vs bare metal', I think high i/o instances full a huge
niche in their lineup. Dollar for dollar, I'm coming around to the
point of view that dealing with aws is a cheaper/more effective
solution than renting out space from a data center or (even worse)
running your own data center unless you're very large or have other
special requirements. Historically the problem with AWS is that you
had no solution for highly transaction bound systems which forced you
to split your environment which ruined most of the benefit, and they
fixed that.Hi Merlin,
I am sure you can get good performance with these.
I simply focused on the part where seb said he was testing his app, and
since you can get some really high data throughput (by my very modest
standards anyway) with a good machine, I wondered why he did it.Maybe seb is planning for an application that already has hundreds of
users after all, I did oversee that option.To Sébastien : please use 'reply all' to send your reply to the list
Le mardi 21 août 2012 à 10:29 -0400, Sébastien Lorion a écrit :
Could you elaborate on the complexity you mention ? Setting up a machine
on Amazon, even with a script, is quite simple. As for the pricing you
give, it can be matched on Amazon using Micro or small instances, which
would be adequate given your load average.Well, it _has_ to be more complicated to use AWS than a bare machine,
because of the added layer?--
Vincent Veyron
http://vincentveyron.com/
Gestion informatique des sinistres d'assurances et des dossiers
contentieux pour le service juridique
On 08/21/2012 09:40 PM, David Boreham wrote:
On 8/21/2012 2:18 AM, Vincent Veyron wrote:
I wonder : is there a reason why you have to go through the complexity
of such a setup, rather than simply use bare metal and get good
performance with simplicity?In general I agree -- it is much (much!) cheaper to buy tin and deploy
yourself vs any of the current cloud services.However, there are plenty of counterexample use cases : for example what
if you want one of these machines for a week only?
Another one : what if you are a venture capitalist funding 10 companies
with questionable business models where you expect only one to succeed?
AWS saves you from the headache of selling 500 machines on eBay...
Dedibox appears to be a hosting company that offers dedicated machines.
He appears to be suggesting that buying access to real hardware in a
datacenter (if not buying the hardware yourself) is more cost effective
and easier to manage than using "cloud" style services with more
transient hosts like EC2 offers. At least that's how I understood it.
Vincent?
I wasn't sure what Vincent meant until I did an `mtr` on his host
address, either.
redirects to
A look at their product page suggests that they're at least claiming the
machines are dedicated:
http://www.online.net/serveur-dedie/offre-dedibox-sc.xhtml
running Via Nano (Nano U2250) CPUs on Dell VX11-VS8 machines. The VS8
appears to be a blade:
http://www.flickr.com/photos/netbooknews/3537912243/
so yeah, a dedicated server for ᅵ15/month. That's *AWESOME* when you
mostly need storage and you don't care about performance or storage
reliability; it's a local HDD so you get great gobs of storage w/o
paying per GB.
--
Craig Ringer
Le mercredi 22 aoᅵt 2012 ᅵ 13:15 +0800, Craig Ringer a ᅵcrit :
He appears to be suggesting that buying access to real hardware in a
datacenter (if not buying the hardware yourself) is more cost effective
and easier to manage than using "cloud" style services with more
transient hosts like EC2 offers. At least that's how I understood it.
Hi Craig,
Actually, my comments about costs were misleading : I simply reacted to
the fact that the OP wanted to test his application for high
performance, and thought that it would be easier with bare metal rather
than with AWS, because you have less parameters to control this way.
Also, I'll admit that I jumped the gun without reading about the SSD
offer by Amazon. Still, I would test first with a machine that I
control, but it maybe that Sᅵbastien already did that.
I am curious to know what kind of application requires 10s to 100s of
instances with a PostgreSQL database, because that could get unwieldy
with big data (which I assumed from the high performance specification)
--
Vincent Veyron
http://marica.fr/
Gestion informatique des sinistres d'assurances et des dossiers contentieux pour le service juridique
Vincent, I would appreciate that you stop assuming things based on zero
information about what I am doing. I understand that you are trying to be
helpful, but I can assure you that going bare-metal only does not make any
sense in my context.
Sébastien
On Wed, Aug 22, 2012 at 12:44 PM, Vincent Veyron <vv.lists@wanadoo.fr>wrote:
Show quoted text
Le mercredi 22 août 2012 à 13:15 +0800, Craig Ringer a écrit :
He appears to be suggesting that buying access to real hardware in a
datacenter (if not buying the hardware yourself) is more cost effective
and easier to manage than using "cloud" style services with more
transient hosts like EC2 offers. At least that's how I understood it.Hi Craig,
Actually, my comments about costs were misleading : I simply reacted to
the fact that the OP wanted to test his application for high
performance, and thought that it would be easier with bare metal rather
than with AWS, because you have less parameters to control this way.Also, I'll admit that I jumped the gun without reading about the SSD
offer by Amazon. Still, I would test first with a machine that I
control, but it maybe that Sébastien already did that.I am curious to know what kind of application requires 10s to 100s of
instances with a PostgreSQL database, because that could get unwieldy
with big data (which I assumed from the high performance specification)--
Vincent Veyron
http://marica.fr/
Gestion informatique des sinistres d'assurances et des dossiers
contentieux pour le service juridique
Just looking into High IO instances for a DB deployment. In order to get past 1TB, we are looking at RAID-0. I have heard (http://hackerne.ws/item?id=4266119) there might be a problem if TRIM isn't supported. Does anyone know if it is and has anyone used RAID-0 on these instances? (Linux of course…)
Show quoted text
On Aug 21, 2012, at 9:36 AM, Merlin Moncure wrote:
On Tue, Aug 21, 2012 at 12:33 AM, Sébastien Lorion
<sl@thestrangefactory.com> wrote:Hello,
Since Amazon has added new high I/O instance types and EBS volumes, anyone
has done some benchmark of PostgreSQL on them ?http://perspectives.mvdirona.com/2012/07/20/IOPerformanceNoLongerSucksInTheCloud.aspx
http://perspectives.mvdirona.com/2012/08/01/EBSProvisionedIOPSOptimizedInstanceTypes.aspx
http://aws.typepad.com/aws/2012/08/fast-forward-provisioned-iops-ebs.htmlI will be testing my app soon, but was curious to know if others have done
some tests so I can compare / have a rough idea to what to expect. Looking
on Google, I found an article about MySQL
(http://palominodb.com/blog/2012/07/24/palomino-evaluates-amazon%E2%80%99s-new-high-io-ssd-instances),
but nothing about PostgresSQL.here's a datapoint, stock config:
pgbench -i -s 500
pgbench -c 16 -T 60
number of transactions actually processed: 418012
tps = 6962.607292 (including connections establishing)
tps = 6973.154593 (excluding connections establishing)not too shabby. this was run by a friend who is evaluating high i/o
instances for their high load db servers. we didn't have time to
kick off a high scale read only test unfortunately.Regarding 'AWS vs bare metal', I think high i/o instances full a huge
niche in their lineup. Dollar for dollar, I'm coming around to the
point of view that dealing with aws is a cheaper/more effective
solution than renting out space from a data center or (even worse)
running your own data center unless you're very large or have other
special requirements. Historically the problem with AWS is that you
had no solution for highly transaction bound systems which forced you
to split your environment which ruined most of the benefit, and they
fixed that.merlin
Import Notes
Resolved by subject fallback
On Wednesday, August 22, 2012 04:10:01 PM Andrew Hannon wrote:
Just looking into High IO instances for a DB deployment. In order to get
past 1TB, we are looking at RAID-0. I have heard
(http://hackerne.ws/item?id=4266119) there might be a problem if TRIM isn't
supported. Does anyone know if it is and has anyone used RAID-0 on these
instances? (Linux of course…)
Just use LVM striping. If it turns out to be an issue; that seems to be mostly
conjecture.
I note that the SSDs are only instance storage. The data will be gone when the
instance goes away. I have used instance storage in replicated setups but it
always feels rather fragile unless your data really is transient or you can
maintain 2 replicas.
Their other new service, provisioned IOPS for EBS, might be more useful for a
persistent database. Although not nearly SSD speeds, of course.
Le mercredi 22 aoᅵt 2012 ᅵ 13:30 -0400, Sᅵbastien Lorion a ᅵcrit :
Vincent, I would appreciate that you stop assuming things based on
zero information about what I am doing. I understand that you are
trying to be helpful, but I can assure you that going bare-metal only
does not make any sense in my context.
Dude,
I would appreciate you realize that approaching a newsgroup while
providing zero information about what you are doing (in your own words)
is not the best way to get relevant responses to your question.
Ignoring repeated requests for information does not help, castigating
people trying to help for not having said information at least shows a
certain consistency on your part.
Lest we ridicule ourselves publicly, I suggest we leave the discussion
at that and wish you luck in your endeavor.
Vincent Veyron
On Thu, Aug 23, 2012 at 7:39 AM, Vincent Veyron <vv.lists@wanadoo.fr> wrote:
Lest we ridicule ourselves publicly, I suggest we leave the discussion
at that and wish you luck in your endeavor.
If anyone has an answer to his question, I'd appreciate hearing it,
despite any faux pas that the OP has committed.
Vincent,
The original question can be summed up by "how is general performance of
PostgreSQL on Amazon IOPS". I fail to understand why that would require me
to explain the specifics of my application and/or my market. The only one
asking for that information is you, while others have provided useful
answers, for which I am very grateful.
p.s. My name is not "dude" or "seb", we have not raised the pigs together
...
Sébastien
On Thu, Aug 23, 2012 at 7:39 AM, Vincent Veyron <vv.lists@wanadoo.fr> wrote:
Show quoted text
Le mercredi 22 août 2012 à 13:30 -0400, Sébastien Lorion a écrit :
Vincent, I would appreciate that you stop assuming things based on
zero information about what I am doing. I understand that you are
trying to be helpful, but I can assure you that going bare-metal only
does not make any sense in my context.Dude,
I would appreciate you realize that approaching a newsgroup while
providing zero information about what you are doing (in your own words)
is not the best way to get relevant responses to your question.Ignoring repeated requests for information does not help, castigating
people trying to help for not having said information at least shows a
certain consistency on your part.Lest we ridicule ourselves publicly, I suggest we leave the discussion
at that and wish you luck in your endeavor.Vincent Veyron
On 08/23/2012 07:39 PM, Vincent Veyron wrote:
Le mercredi 22 aoᅵt 2012 ᅵ 13:30 -0400, Sᅵbastien Lorion a ᅵcrit :
Vincent, I would appreciate that you stop assuming things based on
zero information about what I am doing. I understand that you are
trying to be helpful, but I can assure you that going bare-metal only
does not make any sense in my context.Dude,
I would appreciate you realize that approaching a newsgroup while
providing zero information about what you are doing
In this case, what he's doing is seeking generalized performance
measurements. I don't think details were particularly necessary until it
got pulled off-track.
I'll be interested to hear if you have any results Sᅵbastien, or if
anyone else does. It's good to have data on the increasingly popular
cloud platforms out there.
--
Craig Ringer
On Wed, Aug 22, 2012 at 4:12 PM, Alan Hodgson <ahodgson@simkin.ca> wrote:
On Wednesday, August 22, 2012 04:10:01 PM Andrew Hannon wrote:
Just looking into High IO instances for a DB deployment. In order to get
past 1TB, we are looking at RAID-0. I have heard
(http://hackerne.ws/item?id=4266119) there might be a problem if TRIM isn't
supported. Does anyone know if it is and has anyone used RAID-0 on these
instances? (Linux of course…)Just use LVM striping. If it turns out to be an issue; that seems to be mostly
conjecture.I note that the SSDs are only instance storage. The data will be gone when the
instance goes away. I have used instance storage in replicated setups but it
always feels rather fragile unless your data really is transient or you can
maintain 2 replicas.Their other new service, provisioned IOPS for EBS, might be more useful for a
persistent database. Although not nearly SSD speeds, of course.
Yeah -- I should have mentioned that: you absolutely must run hs/sr or
some other strategy that maintains your data. I guess you might as
well turn off fsync, right?
merlin
On 08/23/12 6:49 AM, Craig Ringer wrote:
In this case, what he's doing is seeking generalized performance
measurements. I don't think details were particularly necessary until
it got pulled off-track.
"42"
performance measurements without a very narrow definition of
'performance' are useless. depending on the nature of the application
workload, postgres can stress completely different aspects of the system
(cpu vs read IO performance vs write IO performance being the big three).
--
john r pierce N 37, W 122
santa cruz ca mid-left coast