Hi,
On Fri, Jan 12, 2024 at 10:14:38PM +0000, Cary Huang wrote:
> I think it is good to warn the user about the increased allocation of
> memory for certain parameters so that they do not abuse it by setting
> it to a huge number without knowing the consequences.
Right, and I think it might be useful to log (i.e. at LOG not DEBUG3
level, with a nicer message) the amount of memory we allocate on
startup, that is just one additional line per instance lifetime but
might be quite useful to admins. Or maybe two lines if we log whether we
could allocate it as huge pages or not as well:
|2024-03-08 16:46:13.117 CET [237899] DEBUG: invoking IpcMemoryCreate(size=145145856)
|2024-03-08 16:46:13.117 CET [237899] DEBUG: mmap(146800640) with MAP_HUGETLB failed, huge pages disabled: Cannot
allocatememory
> It is true that max_connections can increase the size of proc array
> and other resources, which are allocated in the shared buffer, which
> also means less shared buffer to perform regular data operations.
AFAICT, those resources are allocated on top of shared_buffers, i.e. the
total allocated memory is shared_buffers + (some resources) *
max_connections + (other resources) * other_factors.
> Instead of stating that higher max_connections results in higher
> allocation, It may be better to tell the user that if the value needs
> to be set much higher, consider increasing the "shared_buffers"
> setting as well.
Only if what you say above is true and I am at fault.
Michael