pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Andrew Kerber <andrew.kerber@gmail.com>
To: Robert Klemme <shortcutter@googlemail.com>
Cc: Andreas Kretschmer <andreas@a-kretschmer.de>
Cc: pgsql-performance@lists.postgresql.org
Subject: Re: OT: Performance of VM
Date: Sat, 10 Feb 2018 08:58:41 -0600
Message-ID: <17D5011A-5D52-454F-B8A6-BE69CDD0878B@gmail.com> (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>

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




view thread (7+ messages)  latest in thread

Message-ID: <17D5011A-5D52-454F-B8A6-BE69CDD0878B@gmail.com>
Permalink:  ../17D5011A-5D52-454F-B8A6-BE69CDD0878B@gmail.com/
Also on:    postgresql.org/message-id/17D5011A-5D52-454F-B8A6-BE69CDD0878B@gmail.com

 · 

reply

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: andrew.kerber@gmail.com, shortcutter@googlemail.com, andreas@a-kretschmer.de, pgsql-performance@lists.postgresql.org
  Subject: Re: OT: Performance of VM
  In-Reply-To: <17D5011A-5D52-454F-B8A6-BE69CDD0878B@gmail.com>

* 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