From: Mark Kirkwood <mark.kirkwood@catalyst.net.nz>
To: Robert Klemme <shortcutter@googlemail.com>
To: Andrew Kerber <andrew.kerber@gmail.com>
Cc: Andreas Kretschmer <andreas@a-kretschmer.de>
Cc: pgsql-performance@lists.postgresql.org
Subject: Re: OT: Performance of VM
Date: Wed, 14 Feb 2018 16:43:50 +1300
Message-ID: <f65ce4d6-ee35-2c83-2cd3-bccb15b57986@catalyst.net.nz> (raw)
In-Reply-To: <CAM9pMnMQGTBPgbHSYE91NUNcZsrryTWbQ1ior0M-=Bcvk-CVKQ@mail.gmail.com>
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>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: mark.kirkwood@catalyst.net.nz, shortcutter@googlemail.com, andrew.kerber@gmail.com, andreas@a-kretschmer.de, pgsql-performance@lists.postgresql.org
Subject: Re: OT: Performance of VM
In-Reply-To: <f65ce4d6-ee35-2c83-2cd3-bccb15b57986@catalyst.net.nz>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox