On Tue, Feb 10, 2004 at 01:20:32PM -0700, Ed L. wrote:
> On Friday January 30 2004 6:06, Martijn van Oosterhout wrote:
> > On Fri, Jan 30, 2004 at 03:19:56PM -0700, Ed L. wrote:
> > >
> > > I'm also curious about the relationship of DB shared buffer cache to
> > > the linux/hpux kernel caches. ...
> >
> > Whenever the database needs a block not in memory it get loaded and ends
> > up in both the OS cache and the DB cache. The difference between getting
> > a block out of DB cache and OS cache is very, very small compared to
> > loading off disk.
>
> So the OS cache and the DB cache may well have duplicate copies of the data?
> With OS cache being more susceptible to preemption from other processes?
Will have. Any time postgresql does a read() the kernel is copying a buffer
from it's cache to postgresql's internal cache. The kernel cache is more
susceptable to reuse by other processes, but it's still double.
> > Finally, at least on Linux, the shared memory postgres uses for cache can
> > also be swapped out making it very difficult to determine the correct
> > value.
>
> What would cause DB shared memory to be swapped out in linux? I thought it
> was all pre-allocated at pgsql startup. Is this the "well its not really
> pre-allocated but rather supplied on demand" story? I think I saw some
> sort of kernel parameter controlling a similar (same?) policy...
Memory pressure. Same rules apply as for everything else I beleive. If you
allocate a huge amount to shared memory, fill it up and then don't use it
for a while while the rest of the system needs the memory, it'll get swapped
out.
I generally give Postgresql about 64-128MB of shared memory, which covers
all of the system tables and the most commonly used small tables. The rest
of the memory (this is a 1GB machine) I leave for the kernel to manage for
the very large tables.
I think giving postgresql half your memory is couterproductive.
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> (... have gone from d-i being barely usable even by its developers
> anywhere, to being about 20% done. Sweet. And the last 80% usually takes
> 20% of the time, too, right?) -- Anthony Towns, debian-devel-announce