Re: Setting effective_io_concurrency in VM?
Whats the guest OS? I have been able to get Oracle to perform just as well on Virtuals as it does on Physicals. I suspect the settings are pretty similar. On Mon, Nov 27, 2017 at 3:06 PM, Fernando Hevia wrote: > > > El 27 nov. 2017 15:24, "Don Seiler" escribió: > > Good afternoon. > > We run Postgres (currently 9.2, upgrading to 9.6 shortly) in VMWare ESX > machines. We currently have effective_io_concurrency set to the default of > 1. I'm told that the data volume is a RAID 6 with 14 data drives and 2 > parity drives. I know that RAID10 is recommended, just working with what > I've inherited for now (storage is high-end HP 3Par and HP recommended RAID > 6 for best performance). > > Anyway, I'm wondering if, in a virtualized environment with a VM > datastore, it makes sense to set effective_io_concurrency closer to the > number of data drives? > > I'd also be interested in hearing how others have configured their > PostgreSQL instances for VMs (if there's anything special to think about). > > > > If the storage was exclusively for the Postgres box I'd try > effective_io_concurrency somewhere between 8 and 12. Since it is probably > not, it will depend on the load the other VMs exert on the storage. > Assuming the storage isnt already stressed and you need the extra IOPS, you > could test values between 4 and 8. You can of course be a lousy team player > and have PG paralelize as much as it can, but this eventually will piss > off the storage or vmware manager, which is never good as they can limit > your IO throughput at the virtualization or storage layers. > > Cheers. > > > > -- Andrew W. Kerber 'If at first you dont succeed, dont take up skydiving.'
Re: OT: Performance of VM
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. On Mon, Feb 5, 2018 at 7:26 AM, Andreas Kretschmer wrote: > > > Am 05.02.2018 um 14:14 schrieb Thomas Güttler: > >> What do you suggest to get some reliable figures? >> > > sar is often recommended, see https://blog.2ndquadrant.com/i > n-the-defense-of-sar/. > > Can you exclude other reasons like vacuum / vacuum freeze? > > > > Regards, Andreas > > -- > 2ndQuadrant - The PostgreSQL Support Company. > www.2ndQuadrant.com > > > -- Andrew W. Kerber 'If at first you dont succeed, dont take up skydiving.'
Re: OT: Performance of VM
I am consultant that specializes in virtualizing oracle enterprise level
workloads. I’m picking up Postgres as a secondary skill. You are right if you
don’t manage it properly, you can have problems running enterprise workloads on
vm s. But it can be done with proper management. And the HA and DR advantages
of virtual systems are huge.
Sent from my iPhone
> On Feb 10, 2018, at 5:20 AM, Robert Klemme wrote:
>
>> On Mon, Feb 5, 2018 at 5:22 PM, Andrew Kerber
>> 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/
