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.
Kind regards
robert
--
[guy, jim, charlie].each {|him| remember.him do |as, often| as.you_can
- without end}
http://blog.rubybestpractices.com/