From: | Michael Banck <mbanck(at)gmx(dot)net> |
---|---|
To: | Robert Treat <rob(at)xzilla(dot)net> |
Cc: | Cary Huang <cary(dot)huang(at)highgo(dot)ca>, 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-10 14:24:05 |
Message-ID: | 65edc286.050a0220.ab68f.397b@mx.google.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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 <mbanck(at)gmx(dot)net> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Gustafsson | 2024-03-10 14:32:12 | Re: pg_dump include/exclude fails to error |
Previous Message | Magnus Hagander | 2024-03-10 14:22:58 | pg_dump include/exclude fails to error |