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
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 |