Re: palloc() too large on pg_buffercache with large shared_buffers

From: Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: palloc() too large on pg_buffercache with large shared_buffers
Date: 2016-09-14 23:59:02
Message-ID: 9A28C8860F777E439AA12E8AEA7694F80122A7BD@BPXM15GP.gisp.nec.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On Wed, Sep 14, 2016 at 12:13 AM, Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com> wrote:
> > It looks to me pg_buffercache tries to allocate more than 1GB using
> > palloc(), when shared_buffers is more than 256GB.
> >
> > # show shared_buffers ;
> > shared_buffers
> > ----------------
> > 280GB
> > (1 row)
> >
> > # SELECT buffers, d.datname, coalesce(c.relname, '???')
> > FROM (SELECT count(*) buffers, reldatabase, relfilenode
> > FROM pg_buffercache group by reldatabase, relfilenode) b
> > LEFT JOIN pg_database d ON d.oid = b.reldatabase
> > LEFT JOIN pg_class c ON d.oid = (SELECT oid FROM pg_database
> > WHERE datname = current_database())
> > AND b.relfilenode = pg_relation_filenode(c.oid)
> > ORDER BY buffers desc;
> > ERROR: invalid memory alloc request size 1174405120
> >
> > It is a situation to use MemoryContextAllocHuge(), instead of palloc().
> > Also, it may need a back patching?
>
> I guess so. Although it's not very desirable for it to use that much
> memory, I suppose if you have a terabyte of shared_buffers you
> probably have 4GB of memory on top of that to show what they contain.
>
Exactly. I found this problem when a people asked me why shared_buffers=280GB
is slower than shared_buffers=128MB to scan 350GB table.
As I expected, most of shared buffers are not in-use and it also reduced
amount of free memory; usable for page-cache.

Thanks,
--
NEC Business Creation Division / PG-Strom Project
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andreas Karlsson 2016-09-15 00:03:03 Re: OpenSSL 1.1 breaks configure and more
Previous Message Tom Lane 2016-09-14 23:37:08 Re: Tracking timezone abbreviation removals in the IANA tz database