Re: Re: Memory Tuning

> Bruno Wolff III <bruno@wolff.to> writes:
> > Should I leave postgres tuning alone and let Linux use all of the memory
> > for buffer caching?
>
> You shouldn't try to make Postgres consume *all* of memory for buffers;
> for one thing, if the shmem region is too large then (at least on some
> Unixen, not sure about Linux) the kernel might decide to swap out parts
> of it.  That'd be counterproductive.  However:

If it pages out, it also maps that shared virtual memory into every
forked backend.  That can be lots of page tables.

>
> > Is there any good reason to increase the number of buffers per backend over
> > the default of 2?
>
> Yes.  Particularly so under 7.1 --- WAL likes to have a lot of buffers
> so that it doesn't have to write data to data files too often.  I'd
> recommend perhaps a few thousand buffers depending on how much RAM you
> have (maybe 10-20% of your physical RAM would be a reasonable upper
> limit on how much space for buffers).
>
> > Why I am not seeing consitant wall clock times for queries? Presumably
> > there is some caching going on, but I am not sure if it is in postgres
> > or in the OS.
>
> Both: we have our buffer area, and then the kernel has its own buffers.
> We can make good use of kernel-level buffering as well as our shared-memory
> buffers, so there's no reason to try to starve the kernel of buffer space.

Our shared buffers allow us to modify them without copying them in/out
of the kernel.

--
  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