Improve logging when using Huge Pages
Shinoda, Noriyoshi <noriyoshi.shinoda@hpe.com>
From: "Shinoda, Noriyoshi (PN Japan FSIP)" <noriyoshi.shinoda@hpe.com>
To: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2021-08-31T05:36:47Z
Lists: pgsql-hackers
Attachments
- huge_pages_log_v1.diff (application/octet-stream) patch v1
Hi Hackers, 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. 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
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Add GUC parameter "huge_pages_status"
- a14354cac0e3 17.0 landed
-
Add check on initial and boot values when loading GUCs
- a73952b79563 16.0 cited
-
Clean up some inconsistencies with GUC declarations
- d9d873bac670 16.0 cited
-
Clean up some GUC declarations and comments
- 7d25958453a6 16.0 cited