Re: Doc tweak for huge_pages?

Поиск
Список
Период
Сортировка
От Catalin Iacob
Тема Re: Doc tweak for huge_pages?
Дата
Msg-id CAHg_5gpEkBiz+nVze++__NWT439oJRC9ZnUgnXfaCTU8TzSkiA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Doc tweak for huge_pages?  (Justin Pryzby <pryzby@telsasoft.com>)
Ответы Re: Doc tweak for huge_pages?  (Catalin Iacob <iacobcatalin@gmail.com>)
Список pgsql-hackers
On Mon, Jan 22, 2018 at 7:23 AM, Justin Pryzby <pryzby@telsasoft.com> wrote:
> Consider this shorter, less-severe sounding alternative:
> "... (but note that this feature can degrade performance of some
> <productname>PostgreSQL</productname> workloads)."

I think the patch looks good now.

As Justin mentions, as far as I see the only arguable piece is how
strong the language should be against Linux THP.

On one hand it can be argued that warning about THP issues is not the
job of this patch. On the other hand this patch does say more about
THP and Googling does bring up a lot of trouble and advice to disable
THP, including:

https://www.postgresql.org/message-id/CANQNgOrD02f8mR3Y8Pi=zFsoL14RqNQA8hwz1r4rSnDLr1b2Cw@mail.gmail.com

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/performance_tuning_guide/s-memory-transhuge

The RedHat article above says "However, THP is not recommended for
database workloads."

I'll leave this to the committer and switch this patch to Ready for Committer.

By the way, Fedora 27 does disable THP by default, they deviate from
upstream in this regard:

[catalin@fedie scripts]$ cat /sys/kernel/mm/transparent_hugepage/enabled
always [madvise] never
[catalin@fedie scripts]$ grep TRANSPARENT /boot/config-4.14.13-300.fc27.x86_64
CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE=y
CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD=y
CONFIG_TRANSPARENT_HUGEPAGE=y
# CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS is not set
CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y
CONFIG_TRANSPARENT_HUGE_PAGECACHE=y

When I have some time I'll try to do some digging into history of the
Fedora kernel package to see if they provide a rationale for changing
the default. That might hint whether it's likely that future RHEL will
change as well.


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Petr Jelinek
Дата:
Сообщение: Re: [PATCH] Logical decoding of TRUNCATE
Следующее
От: Mithun Cy
Дата:
Сообщение: Possible performance regression in version 10.1 with pgbenchread-write tests.