[prev in list] [next in list] [prev in thread] [next in thread] 

List:       pgsql-performance
Subject:    Re: OT: Performance of VM
From:       Mark Kirkwood <mark.kirkwood () catalyst ! net ! nz>
Date:       2018-02-14 3:43:50
Message-ID: f65ce4d6-ee35-2c83-2cd3-bccb15b57986 () catalyst ! net ! nz
[Download RAW message or body]



On 11/02/18 00:20, Robert Klemme wrote:
> On Mon, Feb 5, 2018 at 5:22 PM, Andrew Kerber <andrew.kerber@gmail.com> wrote:
>> Have them check the memory and CPU allocation of the hypervisor, make sure
>> its not overallocated. Make sure the partitions for stroage are aligned (see
>> here:
>> https://blogs.vmware.com/vsphere/2011/08/guest-os-partition-alignment.html)
>> . Install tuned, and enable the throughput performance profile. Oracle has a
>> problem with transparent hugepages, postgres may well have the same problem,
>> so consider disabling transparent hugepages.  There is no reason why
>> performance on a VM would be worse than performance on a physical server.
> Not theoretically. But in practice if you have anything run in a VM
> like in this case you do not know what else is working on that box.
> Analyzing these issues can be really cumbersome and tricky. This is
> why I am generally skeptical of running a resource intensive
> application like a RDBMS in a VM. To get halfway predictable results
> you want at least a minimum of resources (CPU, memory, IO bandwidth)
> reserved for that VM.
>
> Anecdote: we once had a customer run our application in a VM (which is
> supported) and complain about slowness. Eventually we found out that
> they over committed memory - not in sum for all VMs which is common,
> but this single VM had been configured to have more memory than was
> physically available in the machine.
>

Agreed. If you can get the IO layer to have some type of guaranteed 
performance (e.g AWS Provisioned IOPS), then that is a big help. However 
(as you say above) debugging memory and cpu contention (from within the 
guest) is tricky indeed.

Anecdote: concluded VM needed more cpu, so went to 8 to 16 - performance 
got significantly *worse*. We prevailed on the devops guys (this was 
*not* AWS) to migrate the VM is a less busy host. Everything was fine 
thereafter.

regards
Mark

[prev in list] [next in list] [prev in thread] [next in thread]