Re: Improve logging when using Huge Pages

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Improve logging when using Huge Pages
Дата
Msg-id 20221107151458.6puzamerxti2y5in@awork3.anarazel.de
обсуждение исходный текст
Ответ на Re: Improve logging when using Huge Pages  (John Naylor <john.naylor@enterprisedb.com>)
Ответы Re: Improve logging when using Huge Pages
Список pgsql-hackers
Hi,

On 2022-11-06 14:04:29 +0700, John Naylor wrote:
> I think the best thing to do is change huge_pages='on' to log a WARNING and
> fallback to regular pages if the mapping fails. That way, both dev and prod
> can keep the same settings, since 'on' will have both visibility and
> robustness. I don't see a good reason to refuse to start -- seems like an
> anti-pattern.

How would on still have robustness if it doesn't actually do anything other
than cause a WARNING? The use of huge pages can have very substantial effects
on memory usage an performance. And it's easy to just have huge_pages fail,
another program that started could have used huge pages, or some config
variables was changed to incerase shared memory usage...

I am strongly opposed to making 'on' fall back to not using huge pages. That's
what 'try' is for.

I know of people that scripted cluster start so that they start with 'on' and
change the system setting of the number of huge pages according to the error
message.

Greetings,

Andres Freund



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

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: WIN32 pg_import_system_collations
Следующее
От: "Jonathan S. Katz"
Дата:
Сообщение: Re: Draft back-branch release notes are up