Re: Performance on 8CPU's and 32GB of RAM - Mailing list pgsql-performance

From Carlo Stonebanks
Subject Re: Performance on 8CPU's and 32GB of RAM
Date
Msg-id 4F731254987542AF807CA3EDF411D12B@serenity
Whole thread Raw
In response to Re: Performance on 8CPU's and 32GB of RAM  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: Performance on 8CPU's and 32GB of RAM  (Alvaro Herrera <alvherre@commandprompt.com>)
Re: Performance on 8CPU's and 32GB of RAM  ("Scott Marlowe" <scott.marlowe@gmail.com>)
List pgsql-performance
>> 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?


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



pgsql-performance by date:

Previous
From: "Scott Marlowe"
Date:
Subject: Re: Performance on 8CPU's and 32GB of RAM
Next
From: Alvaro Herrera
Date:
Subject: Re: Performance on 8CPU's and 32GB of RAM