Re: Perplexing, regular decline in performance

From: Hugh Ranalli <hugh(at)whtc(dot)ca>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, pgsql-performance(at)lists(dot)postgresql(dot)org
Subject: Re: Perplexing, regular decline in performance
Date: 2019-07-17 14:29:28
Message-ID: CAAhbUMOhmTFUdLHn3TZA9Gh8ijrCVRWmtd0QAkcYKj_kY_5jiQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Wed, 26 Jun 2019 at 15:18, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> > On 2019-Jun-26, Hugh Ranalli wrote:
> >> From my research in preparing for the upgrade, I understood transparent
> >> huge pages were a good thing, and should be enabled. Is this not
> correct?
>
> > It is not.
>
> Yeah ... they would be a good thing perhaps if the quality of the kernel
> implementation were better. But there are way too many nasty corner
> cases, at least with the kernel versions people around here have
> experimented with. You're best off to disable THP and instead manually
> arrange for Postgres' shared memory to use huge pages. I forget where
> to look for docs about doing that, but I think we have some.
>

We've been dealing with some other production issues, so my apologies for
not replying sooner. I'm seeing now that I have confused huge pages with
*transparent* huge pages. We have a maintenance window coming up this
weekend, so we'll disable transparent huge pages and configure huge pages
manually. I found the docs here:
https://www.postgresql.org/docs/11/kernel-resources.html#LINUX-HUGE-PAGES

Thank you very much!

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Alvaro Herrera 2019-07-17 17:55:51 Re: Perplexing, regular decline in performance
Previous Message David G. Johnston 2019-07-17 13:57:27 Re: Searching in varchar column having 100M records