From: | "Shinoda, Noriyoshi (PN Japan FSIP)" <noriyoshi(dot)shinoda(at)hpe(dot)com> |
---|---|
To: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Improve logging when using Huge Pages |
Date: | 2021-08-31 05:36:47 |
Message-ID: | TU4PR8401MB1152EBB0D271F827E2E37A01EECC9@TU4PR8401MB1152.NAMPRD84.PROD.OUTLOOK.COM |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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 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
Attachment | Content-Type | Size |
---|---|---|
huge_pages_log_v1.diff | application/octet-stream | 1.0 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Bossart, Nathan | 2021-08-31 05:37:52 | Re: Estimating HugePages Requirements? |
Previous Message | Andres Freund | 2021-08-31 05:34:48 | Re: Replication slot drop message is sent after pgstats shutdown. |