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

Re: New server to improve performance on our large and busy DB - advice?

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: <pgsql-performance(at)postgresql(dot)org>, "Carlo Stonebanks" <stonec(dot)register(at)sympatico(dot)ca>
Subject: Re: New server to improve performance on our large and busy DB - advice?
Date: 2010-01-20 20:36:39
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
"Carlo Stonebanks" <stonec(dot)register(at)sympatico(dot)ca> wrote:
>>  yeah, the values are at the end.  Sounds like your vacuum
>> settings are too non-aggresive.  Generally this is the vacuum
>> cost delay being too high.
> Of course, I have to ask: what's the down side?
If you make it too aggressive, it could impact throughput or
response time.  Odds are that the bloat from having it not
aggressive enough is currently having a worse impact.
>> Once the fsm gets too blown out of the water, it's quicker
>> to dump and reload the whole DB than to try and fix it.
> My client reports this is what they actualyl do on a monthly
> basis.
The probably won't need to do that with proper configuration and
vacuum policies.
>>> NOTICE:  number of page slots needed (4090224) exceeds
>>> max_fsm_pages (204800)
>>> HINT:  Consider increasing the configuration parameter
>>> "max_fsm_pages" to a value over 4090224.
> Gee, only off by a factor of 20. What happens if I go for this
> number (once again, what's the down side)?
It costs six bytes of shared memory per entry.

In response to

pgsql-performance by date

Next:From: Greg SmithDate: 2010-01-20 21:18:48
Subject: Re: ext4 finally doing the right thing
Previous:From: Greg SmithDate: 2010-01-20 20:34:21
Subject: Re: a heavy duty operation on an "unused" table kills my server

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