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!
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 |