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

Re: Re: Memory Tuning

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruno Wolff III <bruno(at)wolff(dot)to>, Mitch Vincent <mitch(at)venux(dot)net>, pgsql-general(at)postgresql(dot)org
Subject: Re: Re: Memory Tuning
Date: 2001-04-01 00:55:40
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-general
> Bruno Wolff III <bruno(at)wolff(dot)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                        |
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

In response to

pgsql-general by date

Next:From: Tom LaneDate: 2001-04-01 00:57:59
Subject: Re: dynamic field names in a function.
Previous:From: Tom LaneDate: 2001-04-01 00:53:39
Subject: Re: Re: [SQL] Re: pg_dump potential bug -UNIQUE INDEX on PG_SHADOW Dont!! HELP

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