> Bruno Wolff III <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
