From: David Boreham <david_list@boreham.org>
To: pgsql-performance@postgresql.org
Subject: Re: Postgresql in a Virtual Machine
Date: Tue, 26 Nov 2013 09:29:05 -0700
Message-ID: <5294CC51.5090609@boreham.org> (raw)
In-Reply-To: <CAFwQ8rdPnbWhJCL5tK9+CctpjQ8ABvu61Pizesat3oMMcTByOA@mail.gmail.com>
References: <CAHghi5Cj_6KmwaUopF3y=vSjs3Q83VyXQy5DQhfLyP_Zt0yxbA@mail.gmail.com>
<5293B0B9.1060200@vmware.com>
<5294A77F.8050508@cybertec.at>
<CAFwQ8rdPnbWhJCL5tK9+CctpjQ8ABvu61Pizesat3oMMcTByOA@mail.gmail.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-performance>
On 11/26/2013 7:26 AM, Craig James wrote:
>
> For those of us with small (a few to a dozen servers), we'd like to
> get out of server maintenance completely. Can anyone with experience
> on a cloud VM solution comment? Do the VM solutions provided by the
> major hosting companies have the same good performance as the VM's
> that that several have described here?
>
> Obviously there's Amazon's new Postgres solution available. What else
> is out there in the way of "instant on" solutions with
> Linux/Postgres/Apache preconfigured systems? Has anyone used them in
> production?
I've done some work with Heroku and the MySQL flavor of AWS service.
They work, and are convenient, but there are a couple of issues :
1. Random odd (and bad) things can happen from a performance perspective
that you just need to cope with. e.g. I/O will become vastly slower for
periods of 10s of seconds, once or twice a day. If you don't like the
idea of phenomena like this in your system, beware.
2. Your inability to connect with the bare metal may turn out to be a
significant hassle when trying to understand some performance issue in
the future. Tricks that we're used to using such as looking at "iostat"
(or even "top") output are no longer usable because the hosting company
will not give you a login on the host VM. This limitation extends to
many many techniques that have been commonly used in the past and can
become a major headache to the point where you need to reproduce the
system on physical hardware just to understand what's going on with it
(been there, done that...)
For the reasons above I would caution deploying a production service
(today) on a "SaaS" database service like Heroku or Amazon RDS.
Running your own database inside a stock VM might be better, but it can
be hard to get the right kind of I/O for that deployment scenario.
In the case of self-hosted VMWare or KVM obviously you have much more
control and observability.
Heroku had (at least when I last used it, a year ago or so) an
additional issue in that they host on AWS VMs so if something goes wrong
you are talking to one company that is using another company's virtual
machine service. Not a recipe for clarity, good service and hair
retention...
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: david_list@boreham.org
Subject: Re: Postgresql in a Virtual Machine
In-Reply-To: <5294CC51.5090609@boreham.org>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox