pg.ddx.io pgsql-performance@postgresql.org mailing list archive
help / color / mirror / Atom feedOT: Performance of VM
7+ messages / 5 participants
[nested] [flat]
* OT: Performance of VM
@ 2018-02-05 13:14 Thomas Güttler <guettliml@thomas-guettler.de>
0 siblings, 1 reply; 7+ messages in thread
From: Thomas Güttler @ 2018-02-05 13:14 UTC (permalink / raw)
To: pgsql-performance@lists.postgresql.org
This is a bit off-topic, since it is not about the performance of PG itself.
But maybe some have the same issue.
We run PostgreSQL in virtual machines which get provided by our customer.
We are not responsible for the hypervisor and have not access to it.
The IO performance of our application was terrible slow yesterday.
The users blamed us, but it seems that there was something wrong with the hypervisor.
For the next time I would like to have reliable figures, to underline my guess that the hypervisor (and not our
application) is the bottle neck.
I have the vague strategy to make some io performance check every N minutes and record the numbers.
Of course I could do some dirty scripting, but I would like to avoid to re-invent things. I guess this was already
solved by people which have more brain and more experience than I have :-)
What do you suggest to get some reliable figures?
Regards,
Thomas Güttler
--
Thomas Guettler http://www.thomas-guettler.de/
I am looking for feedback: https://github.com/guettli/programming-guidelines
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: OT: Performance of VM
@ 2018-02-05 13:26 Andreas Kretschmer <andreas@a-kretschmer.de>
parent: Thomas Güttler <guettliml@thomas-guettler.de>
0 siblings, 1 reply; 7+ messages in thread
From: Andreas Kretschmer @ 2018-02-05 13:26 UTC (permalink / raw)
To: pgsql-performance@lists.postgresql.org
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/in-the-defense-of-sar/.
Can you exclude other reasons like vacuum / vacuum freeze?
Regards, Andreas
--
2ndQuadrant - The PostgreSQL Support Company.
www.2ndQuadrant.com
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: OT: Performance of VM
@ 2018-02-05 16:22 Andrew Kerber <andrew.kerber@gmail.com>
parent: Andreas Kretschmer <andreas@a-kretschmer.de>
0 siblings, 2 replies; 7+ messages in thread
From: Andrew Kerber @ 2018-02-05 16:22 UTC (permalink / raw)
To: Andreas Kretschmer <andreas@a-kretschmer.de>; +Cc: pgsql-performance@lists.postgresql.org
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 <andreas@a-kretschmer.de>
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.'
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: OT: Performance of VM
@ 2018-02-05 16:33 Andreas Kretschmer <andreas@a-kretschmer.de>
parent: Andrew Kerber <andrew.kerber@gmail.com>
1 sibling, 0 replies; 7+ messages in thread
From: Andreas Kretschmer @ 2018-02-05 16:33 UTC (permalink / raw)
To: Andrew Kerber <andrew.kerber@gmail.com>; +Cc: pgsql-performance@lists.postgresql.org
Am 05.02.2018 um 17:22 schrieb Andrew Kerber:
> Oracle has a problem with transparent hugepages, postgres may well
> have the same problem, so consider disabling transparent hugepages.
yes, that's true.
Regards, Andreas
--
2ndQuadrant - The PostgreSQL Support Company.
www.2ndQuadrant.com
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: OT: Performance of VM
@ 2018-02-10 11:20 Robert Klemme <shortcutter@googlemail.com>
parent: Andrew Kerber <andrew.kerber@gmail.com>
1 sibling, 2 replies; 7+ messages in thread
From: Robert Klemme @ 2018-02-10 11:20 UTC (permalink / raw)
To: Andrew Kerber <andrew.kerber@gmail.com>; +Cc: Andreas Kretschmer <andreas@a-kretschmer.de>; pgsql-performance@lists.postgresql.org
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/
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: OT: Performance of VM
@ 2018-02-10 14:58 Andrew Kerber <andrew.kerber@gmail.com>
parent: Robert Klemme <shortcutter@googlemail.com>
1 sibling, 0 replies; 7+ messages in thread
From: Andrew Kerber @ 2018-02-10 14:58 UTC (permalink / raw)
To: Robert Klemme <shortcutter@googlemail.com>; +Cc: Andreas Kretschmer <andreas@a-kretschmer.de>; pgsql-performance@lists.postgresql.org
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/
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: OT: Performance of VM
@ 2018-02-14 03:43 Mark Kirkwood <mark.kirkwood@catalyst.net.nz>
parent: Robert Klemme <shortcutter@googlemail.com>
1 sibling, 0 replies; 7+ messages in thread
From: Mark Kirkwood @ 2018-02-14 03:43 UTC (permalink / raw)
To: Robert Klemme <shortcutter@googlemail.com>; Andrew Kerber <andrew.kerber@gmail.com>; +Cc: Andreas Kretschmer <andreas@a-kretschmer.de>; pgsql-performance@lists.postgresql.org
On 11/02/18 00:20, Robert Klemme 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.
>
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
^ permalink raw reply [nested|flat] 7+ messages in thread
end of thread, other threads:[~2018-02-14 03:43 UTC | newest]
Thread overview: 7+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2018-02-05 13:14 OT: Performance of VM Thomas Güttler <guettliml@thomas-guettler.de>
2018-02-05 13:26 ` Andreas Kretschmer <andreas@a-kretschmer.de>
2018-02-05 16:22 ` Andrew Kerber <andrew.kerber@gmail.com>
2018-02-05 16:33 ` Andreas Kretschmer <andreas@a-kretschmer.de>
2018-02-10 11:20 ` Robert Klemme <shortcutter@googlemail.com>
2018-02-10 14:58 ` Andrew Kerber <andrew.kerber@gmail.com>
2018-02-14 03:43 ` Mark Kirkwood <mark.kirkwood@catalyst.net.nz>
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