From: Rafael Martinez <r.m.guerrero@usit.uio.no>
To: Lee Nguyen <leemobile@gmail.com>
Cc: pgsql-performance@postgresql.org <pgsql-performance@postgresql.org>
Subject: Re: Postgresql in a Virtual Machine
Date: Tue, 26 Nov 2013 10:47:35 +0100
Message-ID: <52946E37.1050001@usit.uio.no> (raw)
In-Reply-To: <CAHghi5Cj_6KmwaUopF3y=vSjs3Q83VyXQy5DQhfLyP_Zt0yxbA@mail.gmail.com>
References: <CAHghi5Cj_6KmwaUopF3y=vSjs3Q83VyXQy5DQhfLyP_Zt0yxbA@mail.gmail.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-performance>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 11/25/2013 09:01 PM, Lee Nguyen wrote:
> Hi,
>
> Having attended a few PGCons, I've always heard the remark from a
> few presenters and attendees that Postgres shouldn't be run inside
> a VM. That bare metal is the only way to go.
>
[........]
Hello
This was true some years ago. In our experience, this is not true
anymore if you are not running a very demanding system that will be a
challenge even running on metal. It should work well for most use
cases if your infrastructure is configured correctly.
This year we have moved all our postgreSQL servers (45+) to a VMware
cluster running vSphere 5.1. We are also almost finished moving all
our oracle databases to this cluster too. More than 100 virtual
servers and some thousands databases are running without problems in
our VM environment.
In our experience, VMware vSphere 5.1 makes a huge different in IO
performance compared to older versions. Our tests against a storage
solution connected to vm servers and metal servers last year, did not
show any particular difference in performance between them. Some tips:
* We use a SAN via Fibre Channel to storage our data. Be sure to have
enough active FC channels for your load. Do not even think to use NFS
to connect your physical nodes to your SAN.
* We are using 10GigE to interconnect the physical nodes in our
cluster. This helps a lot when moving VM servers between nodes.
* Don't use in production the snapshot functionality in VM clusters.
* Don't over provision resources, specially memory.
* Use paravirtualized drivers.
* As usual, your storage solution will define the limits in
performance of your VM cluster.
We have gained a lot in flexibility and manageability without losing
performance, the benefits in these areas are many when you
administrate many servers/databases.
regards,
- --
Rafael Martinez Guerrero
Center for Information Technology
University of Oslo, Norway
PGP Public Key: http://folk.uio.no/rafael/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
iEYEARECAAYFAlKUbjcACgkQBhuKQurGihTpHQCeIDkjR/BFM61V2ft72BYd2SBr
sowAnRrscNmByay3KL9iicpGUYcb2hv6
=Qvey
-----END PGP SIGNATURE-----
--
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: r.m.guerrero@usit.uio.no, leemobile@gmail.com
Subject: Re: Postgresql in a Virtual Machine
In-Reply-To: <52946E37.1050001@usit.uio.no>
* 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