Josh Berkus wrote:
>Chris,
>
>
>
>>Sorry for the confusion here. I can't run any sort of vacuum durin the day
>>due to performance hits. However, I have run vacuums at night. Several
>>nights a week I run a vacuumdb -f -z on all of the clusters. I can take
>>serveral hours to complete, but it does complete.
>>
>>
>
>Well, here's your first problem: since your FSM pages is low, and you're only
>vacuuming once a day, you've got to have some serious table and index bloat.
>SO you're going to need to do VACUUM FULL on all of your databases, and then
>REINDEX on all of your indexes.
>
>After that, raise your max_fsm_pages to something useful, like 1,000,000. Of
>course, data on your real rate of updates would help more.
>
>If you're getting severe disk choke when you vacuum, you probably are I/O
>bound. You may want to try something which allows you to vacuum one table
>at a time, either pg_autovacuum or a custom script.
>
>
>
Tom and Josh recently gave me some help about setting the fsm settings
which was quite useful. The full message is at
http://archives.postgresql.org/pgsql-performance/2004-04/msg00229.php
and the 'most interesting' posrtion was:
Actually, since he's running 7.4, there's an even better way. Do a
"VACUUM VERBOSE" (full-database vacuum --- doesn't matter whether you
ANALYZE or not). At the end of the very voluminous output, you'll see
something like
INFO: free space map: 240 relations, 490 pages stored; 4080 total pages needed
DETAIL: Allocated FSM size: 1000 relations + 20000 pages = 178 kB shared memory.
Here, I would need max_fsm_relations = 240 and max_fsm_pages = 4080 to
exactly cover the present freespace needs of my system. I concur with
the suggestion to bump that up a good deal, of course, but that gives
you a real number to start from.
The DETAIL part of the message shows my current settings (which are the
defaults) and what the FSM is costing me in shared memory space.
Good luck
Ron