| From: | "Carlo Stonebanks" <stonec(dot)register(at)sympatico(dot)ca> |
|---|---|
| To: | "'Alvaro Herrera'" <alvherre(at)commandprompt(dot)com> |
| Cc: | <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: Performance on 8CPU's and 32GB of RAM |
| Date: | 2007-09-05 15:57:19 |
| Message-ID: | 4F731254987542AF807CA3EDF411D12B@serenity |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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?
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2007-09-05 16:03:48 | Re: Performance on 8CPU's and 32GB of RAM |
| Previous Message | Scott Marlowe | 2007-09-05 15:45:24 | Re: Performance on 8CPU's and 32GB of RAM |