From: Scott Marlowe <scott.marlowe@gmail.com>
To: Carlo Stonebanks <stonec.register@sympatico.ca>
Cc: Alvaro Herrera <alvherre@commandprompt.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: Performance on 8CPU's and 32GB of RAM
Date: Wed, 5 Sep 2007 11:06:07 -0500
Message-ID: <dcc563d10709050906p762743e4h27ab46c27807bc5d@mail.gmail.com> (raw)
In-Reply-To: <4F731254987542AF807CA3EDF411D12B@serenity>
References: <fbkn5d$cfq$1@news.hub.org>
<20070904230639.GA23731@alvh.no-ip.org>
<4F731254987542AF807CA3EDF411D12B@serenity>
On 9/5/07, Carlo Stonebanks <stonec.register@sympatico.ca> wrote:
> >> Large shared_buffers and Windows do not mix. Perhaps you should leave
> the shmem config low, so that the kernel can cache the file pages.
> <<
>
> Is there a problem BESIDES the one that used to cause windows to fail to
> allocate memory in blocks larger than 1.5GB?
>
> The symptom of this problem was that postgresql would just refuse to
> restart. Microsoft released a patch for this problem and we can now start
> postgresql with larger shared buffers. If this is indeed the problem that
> you refer to - and it has indeed been solved by Microsoft - is there a down
> side to this?
There have been some reports that performance-wise large shared buffer
settings don't work as well on windows as they do on linux / unix.
Don't know myself. Just what I've read.
> >> It sounds like you will need a huge lot of vacuuming effort to keep up.
> Maybe you should lower autovac scale factors so that your tables are
> visited more frequently. A vacuum_delay of 40 sounds like too much
> though.
> <<
>
> Does autovacuum not impede performance while it is vacuuming a table?
Of course vacuum impedes performance. Depends on your I/O subsystem.
By adjusting your vacuum parameters in postgresql.conf, the impact can
be made pretty small. But not vacuuming has a slow but sure
deteriorating effect over time. So, it's generally better to let
autovacuum take care of things and run vacuum with a reasonable set of
parameters so it doesn't eat all your I/O bandwidth.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: scott.marlowe@gmail.com, stonec.register@sympatico.ca, alvherre@commandprompt.com
Subject: Re: Performance on 8CPU's and 32GB of RAM
In-Reply-To: <dcc563d10709050906p762743e4h27ab46c27807bc5d@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox