Re: PostgreSQL performance on a virtual host

Hello,

On Wed, Mar 5, 2008 at 5:40 PM, Bill Moran
<wmoran@collaborativefusion.com> wrote:
> In response to "Ivan Zolotukhin" <ivan.zolotukhin@gmail.com>:
>
> >
>  > We had a bad experience with PostgreSQL running in OpenVZ (year and a
>  > half year ago): OpenVZ kernel killed postmaster with strange signals
>  > from time to time, failcounters of OpenVZ did not worked as expected
>  > in this moments, PostgreSQL fighted for the disk with applications in
>  > other virtual cells, no one from OpenVZ forums was able to help me
>  > with these issues. So this experience was really dissapointing; since
>  > then we use only dedicated systems without kernels patched for
>  > virtualization.
>
>  If your database is busy enough that it's stressing the hardware on a
>  single machine, it's not going to do any better in a VM.  Sounds to me like
>  you were already pushing the limits of the IO capability of that machine ...
>  it's not OpenVZ's fault that it can't make more IO bandwidth available.

The problem actually was that PostgreSQL worked closely to some kernel
limits and kernel simply killed it sometimes without counting that in
corresponding failcounters. And there was no existing OpenVZ
documentation to debug these issues which I think is unacceptable.
Workload (incl. IO load) was moderate, nothing extremal.

I don't like when system kills my PostgreSQL without even telling me
why. Apart from that I think that administrator should be able to
decide himself whether load is high enough to stop some process for it
not to interfere with other virtual cells. OpenVZ with its
documentation and experts on dedicated forum did not provide such
instruments at that time. I would be satisfied with OpenVZ if I'd be
able to tell the system not to kill my PostgreSQL whatever happens,
but I couldn't. So I simply switched to something more reliable.

>  > On Wed, Mar 5, 2008 at 11:54 AM, Moritz Onken <onken@houseofdesign.de> wrote:
>  > > We have very good experiences with openVZ as virtualizer.
>  > >  Since it's not a para virtualization like xen it's very fast. Almost
>  > >  as fast as the host.
>  > >
>  > >  www.openvz.org
>  > >
>  > >  Am 04.03.2008 um 16:43 schrieb Theo Kramer:
>  > >
>  > >
>  > >
>  > >  > Hi
>  > >  >
>  > >  > We are thinking of running a PostgreSQL instance on a virtual host
>  > >  > under
>  > >  > Xen.
>  > >  >
>  > >  > Any thoughts for/against running PostgreSQL on a virtual host would be
>  > >  > much appreciated.
>  > >  >
>  > >  > --
>  > >  > Regards
>  > >  > Theo
>  > >  >
>  > >  >
>  > >  > --
>  > >  > Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org
>  > >  > )
>  > >  > To make changes to your Subscription:
>  > >  > http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.org&extra=pgsql-performance
>  > >
>  > >
>  > >  --
>  > >  Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
>  > >  To make changes to your subscription:
>  > >  http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.org&extra=pgsql-performance
>  > >
>  >
>  > --
>  > Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
>  > To make changes to your subscription:
>  > http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.org&extra=pgsql-performance
>
>
>  --
>  Bill Moran
>  Collaborative Fusion Inc.
>  http://people.collaborativefusion.com/~wmoran/
>
>  wmoran@collaborativefusion.com
>  Phone: 412-422-3463x4023
>
>  ****************************************************************
>  IMPORTANT: This message contains confidential information and is
>  intended only for the individual named. If the reader of this
>  message is not an intended recipient (or the individual
>  responsible for the delivery of this message to an intended
>  recipient), please be advised that any re-use, dissemination,
>  distribution or copying of this message is prohibited. Please
>  notify the sender immediately by e-mail if you have received
>  this e-mail by mistake and delete this e-mail from your system.
>  E-mail transmission cannot be guaranteed to be secure or
>  error-free as information could be intercepted, corrupted, lost,
>  destroyed, arrive late or incomplete, or contain viruses. The
>  sender therefore does not accept liability for any errors or
>  omissions in the contents of this message, which arise as a
>  result of e-mail transmission.
>  ****************************************************************
>