Re: Improve logging when using Huge Pages
От | Julien Rouhaud |
---|---|
Тема | Re: Improve logging when using Huge Pages |
Дата | |
Msg-id | CAOBaU_YGfFyruW4YX6++DifTtBt8bjatz0gMhaTRD=dqV3gdWg@mail.gmail.com обсуждение исходный текст |
Ответ на | Improve logging when using Huge Pages ("Shinoda, Noriyoshi (PN Japan FSIP)" <noriyoshi.shinoda@hpe.com>) |
Ответы |
Re: Improve logging when using Huge Pages
|
Список | pgsql-hackers |
On Tue, Aug 31, 2021 at 1:37 PM Shinoda, Noriyoshi (PN Japan FSIP) <noriyoshi.shinoda@hpe.com> wrote: > > In the current version, when GUC huge_pages=try, which is the default setting, no log is output regardless of the successor failure of the HugePages acquisition. If you want to output logs, you need to set log_min_messages=DEBUG3, butit 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 thatHugePages 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.
В списке pgsql-hackers по дате отправления: