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