Re: Possible bug with shared memory buffers - Mailing list pgsql-general

From Bruce Momjian
Subject Re: Possible bug with shared memory buffers
Date
Msg-id 200201021825.g02IPJm10574@candle.pha.pa.us
Whole thread Raw
In response to Re: Possible bug with shared memory buffers  (Mark Rae <m.rae@inpharmatica.co.uk>)
List pgsql-general
Mark Rae wrote:
> Tom Lane wrote:
> >
> > Mark Rae <m.rae@inpharmatica.co.uk> writes:
> > > Normally the backend process would 'swap in' all 512M of shared
> > > memory when loading, but occasionally after dropping the previous
> > > database, the new backend would only seem to be able to use a
> > > small amount of the shared memory.
> >
> > This is so vague that I'm not even sure what you're complaining about.
> > What do you mean by "only seem to be able to use a small amount of the
> > shared memory"?
> >
>
> I was referring to the memory usage as reported by top,ps etc.
>
> Normally as the data is loaded, the RSS,SIZE,SHARE values for the
> backend would grow towards ~512M.
> However when the problem occurs the memory usage would not grow as normal
> but get 'stuck' at some lower value (about 10M or so).

OK, let me jump in here.  First, I am unsure how the various OS's
determine memory usage when using shared memory.  Do they report the
512mb shared buffers for each backend, none of them, one of them, or
spread the 512mb evenly among all attached backends?

Second, the idea of shared memory being paged out is not attractive to
me.  On FreeBSD, I believe sysctl will allow you to control if the
shared memory is paged out.  Not sure about Linux.  I recommend turning
off shared memory paging and see what happens.  I can imagine
performance taking a major hit if any shared memory is not in RAM.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

pgsql-general by date:

Previous
From: Nate Haggard
Date:
Subject: Re: trigger is holding up the data
Next
From: Tom Lane
Date:
Subject: Re: tuplesort error from create index (?)