On 11/02/18 00:20, Robert Klemme wrote:
On Mon, Feb 5, 2018 at 5:22 PM, Andrew Kerber <andrew.kerber@xxxxxxxxx> 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
