Subject: Re: OT: Performance of VM
To: Robert Klemme <shortcutter@googlemail.com>,
 Andrew Kerber <andrew.kerber@gmail.com>
Cc: Andreas Kretschmer <andreas@a-kretschmer.de>,
 pgsql-performance@lists.postgresql.org
References: <3bc54eb3-135d-692c-47e2-208189a350d7@thomas-guettler.de>
 <91fec1f8-d11d-2413-6b57-5310ab0e3b8a@a-kretschmer.de>
 <CAJvnOJbzmAiwytvpAkLaDC2Y4p=VS+1A_2qou7pyBU5bQPX5CQ@mail.gmail.com>
 <CAM9pMnMQGTBPgbHSYE91NUNcZsrryTWbQ1ior0M-=Bcvk-CVKQ@mail.gmail.com>
From: Mark Kirkwood <mark.kirkwood@catalyst.net.nz>
Message-ID: <f65ce4d6-ee35-2c83-2cd3-bccb15b57986@catalyst.net.nz>
Date: Wed, 14 Feb 2018 16:43:50 +1300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: 
 <CAM9pMnMQGTBPgbHSYE91NUNcZsrryTWbQ1ior0M-=Bcvk-CVKQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Precedence: bulk


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