Skip site navigation (1) Skip section navigation (2)

Re: [GENERAL] PostgreSQL backend process high memory usage issue

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Shianmiin <Shianmiin(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org, pgsql-bugs <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: [GENERAL] PostgreSQL backend process high memory usage issue
Date: 2011-04-13 13:42:00
Message-ID: BANLkTin8dYx+p9AT3TmXvOKto=2HDuKZMQ@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-bugspgsql-general
On Wed, Apr 13, 2011 at 12:29 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Merlin Moncure <mmoncure(at)gmail(dot)com> writes:
>> I think you may have uncovered a leak (I stand corrected).
>
>> The number of schemas in your test is irrelevant -- the leak is
>> happening in proportion to the number of views (set via \setrandom
>> tidx 1 10).  At 1 I don't think it exists at all -- at 100 memory use
>> grows very fast.
>
> I don't think it's a leak, exactly: it's just that the "relcache" entry
> for each one of these views occupies about 100K.  A backend that touches
> N of the views is going to need about N*100K in relcache space.  I can't
> get terribly excited about that.  Trying to reduce the size of the
> relcache would be a net loss for most usage patterns (ie, we'd end up
> increasing the amount of re-fetching from the system catalogs that
> backends would have to do).  And I don't think that this test case has
> much of anything to do with sane application design, anyway.  Do you
> really need that many complex views?  Do you really need to have most
> sessions touching all of them?

Ya, my mistake -- it *felt* like a leak when of course it was not.
100k does seem like an awful lot though -- perhaps this could be
organized better? -- but that's not really the point.  I've coded a
lot of multi schema designs and they tend to either go the one
session/schema route or the connection pooling route.  Either way,
cache memory usage tends to work itself out pretty well (it's never
been a problem for me before at least).  I can't recall anyone ever
even complaining about it in a non synthetic test.

merlin

In response to

Responses

pgsql-bugs by date

Next:From: Tim WallaceDate: 2011-04-13 14:26:21
Subject: Make fails if env var U set
Previous:From: Vlad ArkhipovDate: 2011-04-13 13:07:29
Subject: Re: BUG #5976: Corrupted pages on the production database

pgsql-general by date

Next:From: Rafael MartinezDate: 2011-04-13 13:44:05
Subject: Re: Weird WAL problem - 9.0.3
Previous:From: Adrian KlaverDate: 2011-04-13 13:28:34
Subject: Re: Weird WAL problem - 9.0.3

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group