public inbox for [email protected]  

help / color / mirror / Atom feed

From: Michael Banck <[email protected]>
To: Robert Treat <[email protected]>
Cc: Cary Huang <[email protected]>
Cc: [email protected]
Cc: Roberto Mello <[email protected]>
Subject: Re: [DOC] Add detail regarding resource consumption wrt max_connections
Date: Sun, 10 Mar 2024 15:24:05 +0100
Message-ID: <[email protected]> (raw)
In-Reply-To: <CABV9wwPtyKu4z=i7bTA1OCHEQmQ1+=s_St1HCU3c9-d5pdsc2g@mail.gmail.com>
References: <CAKz==bJBCWrvN77fmuZ2XqD3jazWEb=E80AA4Yv9C9tQ61YDdQ@mail.gmail.com>
	<170509767861.1131.15083983626399995184.pgcf@coridan.postgresql.org>
	<[email protected]>
	<CABV9wwPtyKu4z=i7bTA1OCHEQmQ1+=s_St1HCU3c9-d5pdsc2g@mail.gmail.com>

Hi,

On Sun, Mar 10, 2024 at 09:58:25AM -0400, Robert Treat wrote:
> On Fri, Mar 8, 2024 at 10:47 AM Michael Banck <[email protected]> wrote:
> > 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
> >
> 
> If we were going to add these details (and I very much like the idea),
> I would advocate that we put it somewhere more permanent than a single
> log entry at start-up. Given that database up-times easily run months
> and sometimes years, it is hard to imagine we'd always have access to
> the log files to figure this out on any actively running systems.

Well actually, those two numbers are already available at runtime, via
the shared_memory_size and (from 17 on) huge_pages_status GUCs.

So this would be geared at admins that keeps in long-term storage and
want to know what the numbers were a while ago. Maybe it is not that
interesting, but I think one or two lines at startup would not hurt.


Michael

view thread (4+ messages)

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: [DOC] Add detail regarding resource consumption wrt max_connections
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox