On Mon, Nov 25, 2013 at 4:00 PM, Gudmundsson Martin (mg)
<martin.mg.gudmundsson@volvo.com> wrote:
>
> I would also make sure to check that the hypervisor does write to permanent storage before returning to the VM with
acknowledgement.
>
In the case of ESX, there is no such concern per
http://kb.vmware.com/kb/1008542.
As Heikki commented, VMware recently compared Postgres performance in
an ESX (5.1) VM versus in a comparable native Linux. We saw 1.
ESX-level locking causes no vertical scalability degradation, 2.
Memory oversubscription can indeed be a performance hazard when
consolidating mulitple Postgres VMs on one host. Yet we found moderate
memory oversubscription (up to 20%) might work out fine: we saw <5%
degradation at 20% memory oversubscription in a conventional setup
(where Postgres server uses 25% memory shared_buffers and VM uses
out-of-the-box kernel-level memory ballooning.) Nitty-gritty details
can be found in the whitepaper
http://www.vmware.com/files/pdf/techpaper/vPostgres-perf.pdf
(Disclaimer: I'm a author.)
As many pointed out here, storage is most likely where extra care of
capacity planning can be used when weighing putting Postgres in a VM
versus natively. Our tests (during the same period as those towards
the above observations) read: pgbench default saw ~10% degradation at
28 pgbench clients on a 32-core Intel Sandy Bridge machine; and dbt2
with zero thinking/keying/ time saw ~30% degradation at 28 dbt2
terminals on the same machine. In both cases, the regression is
gradually and increasingly more pronounced as concurrency ramps up
(starting from <5% degradation at 1 client/terminal in both cases.)
Regards,
Dong