Re: Index Problem? - Mailing list pgsql-performance

From Tom Lane
Subject Re: Index Problem?
Date
Msg-id 2408.1082145927@sss.pgh.pa.us
Whole thread Raw
In response to Re: Index Problem?  (Josh Berkus <josh@agliodbs.com>)
Responses Re: Index Problem?  (Ron St-Pierre <rstpierre@syscor.com>)
List pgsql-performance
Josh Berkus <josh@agliodbs.com> writes:
> A better way to set this would be to run VACUUM VERBOSE ANALYZE right after
> doing one of your update batches, and see how many dead pages are being
> reclaimed, and then set max_fsm_pages to that # + 50% (or more).

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.

If you have multiple active databases, the best approach to getting
these numbers is to VACUUM in each one, adding VERBOSE when you do the
last one.  The FSM report is cluster-wide but you want to be sure the
underlying info is up to date for all databases.

>> Also the docs on Varlena show the max_fsm_pages
>> default to be 10,000 but my default was 20,000, looks like that needs
>> updating.

> I don't think the default has been changed.   Anyone?

Yes, I kicked it up for 7.4 because FSM covers indexes too now.
Both the 7.3 and 7.4 defaults are pretty arbitrary of course...

            regards, tom lane

pgsql-performance by date:

Previous
From: Josh Berkus
Date:
Subject: Re: Index Problem?
Next
From: Mike Nolan
Date:
Subject: Re: Long running queries degrade performance