On Mon, Nov 25, 2013 at 4:00 PM, Gudmundsson Martin (mg) <martin.mg.gudmundsson@xxxxxxxxx> 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 -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
