Re: appropriate sort_mem & shared buffers

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Francisco Reyes <lists(at)natserv(dot)com>
Cc: Markus Bertheau <twanger(at)bluetwanger(dot)de>, PostgreSQL Novice <pgsql-novice(at)postgresql(dot)org>
Subject: Re: appropriate sort_mem & shared buffers
Date: 2001-12-31 17:13:12
Message-ID: 13426.1009818792@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-novice

Francisco Reyes <lists(at)natserv(dot)com> writes:
>> But since you didn't
>> say how many concurrent backends you expect to run, this is all just
>> theorizing in the dark.

> What is the relation between number of connections and buffers?

You need to ensure you have enough RAM left over (after allocating the
buffers) for all the backends you want to run. Don't forget that
sort_mem is per-backend, too.

My gut feeling is that a few thousand buffers (corresponding to a few
tens of megabytes of RAM) is the right range for production situations
on most modern machines.

As an example, yesterday I was running some tests of pgbench with scale
factor 50 and 64 clients, on a Linux box with 256MB RAM. At -B 4096
I got about 40 transactions/sec; at -B 8192 I got about 55; at -B 16384
it dropped off to about 32 t/s. vmstat showed considerable swapping
activity in the last case, so evidently I had run the machine out of RAM
by allocating too much to buffers.

> I was thinking that the higher the
> buffer size the longer it would take for the database to allocate the
> memory before it can serve the query.

No. The shared buffers are a static allocation that is made once when
the postmaster starts.

regards, tom lane

In response to

Responses

Browse pgsql-novice by date

  From Date Subject
Next Message Francisco Reyes 2001-12-31 18:02:43 Re: appropriate sort_mem & shared buffers
Previous Message Francisco Reyes 2001-12-31 17:03:01 Re: appropriate sort_mem & shared buffers