pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Bill Moran <wmoran@collaborativefusion.com>
To: Radhika S <radhika.sambamurti@gmail.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: max fsm pages question
Date: Tue, 8 Jul 2008 15:24:57 -0400
Message-ID: <20080708152457.a8a762ec.wmoran@collaborativefusion.com> (raw)
In-Reply-To: <fe27bfd40807081213q4a8bba99yeda5dd748ea235ca@mail.gmail.com>
References: <fe27bfd40807081213q4a8bba99yeda5dd748ea235ca@mail.gmail.com>

In response to "Radhika S" <radhika.sambamurti@gmail.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@collaborativefusion.com
Phone: 412-422-3463x4023



view thread (4+ messages)  latest in thread

Message-ID: <20080708152457.a8a762ec.wmoran@collaborativefusion.com>
Permalink:  ../20080708152457.a8a762ec.wmoran@collaborativefusion.com/
Also on:    postgresql.org/message-id/20080708152457.a8a762ec.wmoran@collaborativefusion.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: wmoran@collaborativefusion.com, radhika.sambamurti@gmail.com
  Subject: Re: max fsm pages question
  In-Reply-To: <20080708152457.a8a762ec.wmoran@collaborativefusion.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox