Re: [DOC] Add detail regarding resource consumption wrt max_connections

From: Michael Banck <mbanck(at)gmx(dot)net>
To: Cary Huang <cary(dot)huang(at)highgo(dot)ca>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org, Roberto Mello <roberto(dot)mello(at)gmail(dot)com>
Subject: Re: [DOC] Add detail regarding resource consumption wrt max_connections
Date: 2024-03-08 15:46:48
Message-ID: 65eb32e8.170a0220.fcc9.ff2f@mx.google.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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 allocate memory

> 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Melanie Plageman 2024-03-08 15:48:44 Re: Confine vacuum skip logic to lazy_scan_skip
Previous Message Melanie Plageman 2024-03-08 15:44:26 Re: Confine vacuum skip logic to lazy_scan_skip