Re: Improve logging when using Huge Pages

From: Julien Rouhaud <rjuju123(at)gmail(dot)com>
To: "Shinoda, Noriyoshi (PN Japan FSIP)" <noriyoshi(dot)shinoda(at)hpe(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Improve logging when using Huge Pages
Date: 2021-08-31 06:57:47
Message-ID: CAOBaU_YGfFyruW4YX6++DifTtBt8bjatz0gMhaTRD=dqV3gdWg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Aug 31, 2021 at 1:37 PM Shinoda, Noriyoshi (PN Japan FSIP)
<noriyoshi(dot)shinoda(at)hpe(dot)com> wrote:
>
> In the current version, when GUC huge_pages=try, which is the default setting, no log is output regardless of the success or failure of the HugePages acquisition. If you want to output logs, you need to set log_min_messages=DEBUG3, but it will output a huge amount of extra logs.
> With huge_pages=try setting, if the kernel parameter vm.nr_hugepages is not enough, the administrator will not notice that HugePages is not being used.
> I think it should output a log if HugePages was not available.

I agree that the message should be promoted to a higher level. But I
think we should also make that information available at the SQL level,
as the log files may be truncated / rotated before you need the info,
and it can be troublesome to find the information at the OS level, if
you're lucky enough to have OS access.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Yugo NAGATA 2021-08-31 07:03:05 Re: Fix around conn_duration in pgbench
Previous Message Bossart, Nathan 2021-08-31 06:52:08 Re: .ready and .done files considered harmful