> > > > 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. Very useful info! > 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.) Interesting reading. There was some earlier comment in this discussion about not using NFS datastores for Postgres VMDK's. Would you think you'd see a difference in scalability behavior or performance in these tests if a NFS datastore would be used instead? Provided the architecture is properly setup for that, with high speed low latency networking, and fast NAS storage. Thanks! > Regards, > Dong -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
