Re: max fsm pages question

From: Bill Moran <wmoran(at)collaborativefusion(dot)com>
To: "Radhika S" <radhika(dot)sambamurti(at)gmail(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: max fsm pages question
Date: 2008-07-08 19:24:57
Message-ID: 20080708152457.a8a762ec.wmoran@collaborativefusion.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

In response to "Radhika S" <radhika(dot)sambamurti(at)gmail(dot)com>:
>
> when i issued the vaccuum cmd, I recieved this message:
>
> echo "VACUUM --full -d ARSys" | psql -d dbname
>
> WARNING: relation "public.tradetbl" contains more than
> "max_fsm_pages" pages with useful free space
> HINT: Consider compacting this relation or increasing the
> configuration parameter "max_fsm_pages".
> NOTICE: number of page slots needed (309616) exceeds max_fsm_pages (153600)
> HINT: Consider increasing the configuration parameter "max_fsm_pages"
> to a value over 309616.
> VACUUM
>
> What does the warning indicate? How will it adversely affect the system.

It means any combination of the following things:
1) You're not vacuuming often enough
2) Your FSM settings are too low
3) You recently had some unusually high update/delete activity on that
table that's exceeded your normal settings for FSM and vacuum and
will need special attention to get back on track.

If you know it's #3, then just take steps to get things back on track
and don't worry about 1 or 2. If you don't think it's #3, then you
may want to increase the frequency of vacuum and/or increase the FSM
settings in your conf file.

You can do a CLUSTER to get that table back in shape, but be sure to
read up on CLUSTER so you understand the implications before you do so.
You can also temporarily raise the FSM settings to allow vacuum to work,
then lower them back down when it's under control again. This is one
of the few circumstances where you may want to VACUUM FULL.

If you don't handle this, that table will continue to grow in size on
the disk, taking up space unnecessarily and probably negatively
impacting performance.

--
Bill Moran
Collaborative Fusion Inc.
http://people.collaborativefusion.com/~wmoran/

wmoran(at)collaborativefusion(dot)com
Phone: 412-422-3463x4023

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2008-07-08 21:39:17 Re: syslog performance when logging big statements
Previous Message Jeremy Harris 2008-07-08 19:24:41 Re: Fusion-io ioDrive