Improve logging when using Huge Pages - Mailing list pgsql-hackers

From Shinoda, Noriyoshi (PN Japan FSIP)
Subject Improve logging when using Huge Pages
Date
Msg-id TU4PR8401MB1152EBB0D271F827E2E37A01EECC9@TU4PR8401MB1152.NAMPRD84.PROD.OUTLOOK.COM
Whole thread Raw
Responses Re: Improve logging when using Huge Pages  (Julien Rouhaud <rjuju123@gmail.com>)
List pgsql-hackers
Hi Hackers,

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.

By the way, in MySQL with almost the same architecture, the following log is output at the Warning level.

[Warning] [MY-012677] [InnoDB] Failed to allocate 138412032 bytes. errno 1
[Warning] [MY-012679] [InnoDB] Using conventional memory pool

The attached small patch outputs a log at the WARNING level when huge_pages = try and if the acquisition of HugePages
fails.

Regards,
Noriyoshi Shinoda


Attachment

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Replication slot drop message is sent after pgstats shutdown.
Next
From: "Bossart, Nathan"
Date:
Subject: Re: Estimating HugePages Requirements?