FSM and VM file
Hi all -
There are lot of FSM and VM files getting generated in the
base directory. Do we need these files and I don't know the reason why these
files are getting generated. I read the documentation, but not able to
follow well. I will read it again. But do we need to keep these files or
there is any process can we run to clean these. Can you please help?
Regards
akp geek wrote on 02.03.2010 22:11:
Hi all -
There are lot of FSM and VM files getting generated in
the base directory. Do we need these files and I don't know the reason
why these files are getting generated. I read the documentation, but not
able to follow well. I will read it again. But do we need to keep these
files or there is any process can we run to clean these. Can you please
help?
Regards
My understanding is that the FSM files are the "Free Space Map" files.
But you should never ever under no circumstance delete files manually from the data directory!
Thomas
Those are the free space map / visibility map files. There is going to be
one of each for every relation.
No worries :-) They are supposed to be there:
http://wiki.postgresql.org/wiki/Segment_Visibility_Map
Don't clean them up, doing so could be disastrous. Actually, if I were
you, I would avoid doing ANY deletes / purges in the data directory.
Everything in there is maintained by the engine.
--Scott
I am doing a replication of one of the database and the size of the slave
database is growing exponentially . Right now the size of master db is 849M
and the slave is 7GB.
When I noticed the base directory on the slave , that's when I noticed the
fsm and vm files and raised the question.
is there any reason why this happens? or is there way to limit the size of
the file.
my master is 8.3 and slave is 8.4
Appreciate your help
Regards
On Tue, Mar 2, 2010 at 4:29 PM, Scott Mead <scott.lists@enterprisedb.com>wrote:
Show quoted text
Those are the free space map / visibility map files. There is going to be
one of each for every relation.No worries :-) They are supposed to be there:
http://wiki.postgresql.org/wiki/Segment_Visibility_Map
Don't clean them up, doing so could be disastrous. Actually, if I were
you, I would avoid doing ANY deletes / purges in the data directory.
Everything in there is maintained by the engine.--Scott
On 02/03/10 21:47, akp geek wrote:
I am doing a replication of one of the database and the size of the slave
database is growing exponentially . Right now the size of master db is 849M
and the slave is 7GB.
my master is 8.3 and slave is 8.4
I'm guessing your slave isn't being vacuumed. Or, perhaps you have a
long-running transaction on the slave that is preventing dead rows from
being cleaned up.
Two useful commands:
vacuum verbose mytable;
This will show you how many rows/pages can/should be cleaned up.
SELECT pg_size_pretty( pg_total_relation_size('mytable') );
This will show you the size of "mytable" (formatted nicely).
--
Richard Huxton
Archonet Ltd
Thank you all for the suggestions. I did a vacuum and the size has gone down
drastically. But still it is not the same size as my master. I am looking
into it
Appreicate your help
On Wed, Mar 3, 2010 at 4:41 AM, Richard Huxton <dev@archonet.com> wrote:
Show quoted text
On 02/03/10 21:47, akp geek wrote:
I am doing a replication of one of the database and the size of the slave
database is growing exponentially . Right now the size of master db is
849M
and the slave is 7GB.my master is 8.3 and slave is 8.4
I'm guessing your slave isn't being vacuumed. Or, perhaps you have a
long-running transaction on the slave that is preventing dead rows from
being cleaned up.Two useful commands:
vacuum verbose mytable;
This will show you how many rows/pages can/should be cleaned up.
SELECT pg_size_pretty( pg_total_relation_size('mytable') );
This will show you the size of "mytable" (formatted nicely).
--
Richard Huxton
Archonet Ltd
On 03/03/10 13:32, akp geek wrote:
Thank you all for the suggestions. I did a vacuum and the size has gone down
drastically. But still it is not the same size as my master. I am looking
into it
Check your autovacuum settings and you should be able to keep things
stable at least.
You might need to cluster tables / restart the replication to get the
best case. Vacuuming needs to be a continual process.
--
Richard Huxton
Archonet Ltd
On Wed, 2010-03-03 at 08:32 -0500, akp geek wrote:
Thank you all for the suggestions. I did a vacuum and the size has
gone down drastically. But still it is not the same size as my master.
I am looking into it
Plain vacuum does not file system size of relations. It just marks dead
spaces are writable. If you haven't vacuumed for a long time, it
probably means that you have lots of space to be reused.
--
Devrim GÜNDÜZ
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz
I just made changes to postgresql.conf to make sure the autovacuum is turned
on and I will update you.. Again thanks for your time
Regards
2010/3/3 Devrim GÜNDÜZ <devrim@gunduz.org>
Show quoted text
On Wed, 2010-03-03 at 08:32 -0500, akp geek wrote:
Thank you all for the suggestions. I did a vacuum and the size has
gone down drastically. But still it is not the same size as my master.
I am looking into itPlain vacuum does not file system size of relations. It just marks dead
spaces are writable. If you haven't vacuumed for a long time, it
probably means that you have lots of space to be reused.
--
Devrim GÜNDÜZ
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz
Hi All -
I have turned on the auto vacuum on the slave and for some
reason the db is getting bloated up. The master size is only 1G and the
slave is at 9.2GB now. I did cluster on couple of tables also. did any one
run into this situation? Can you please help?
Regards
2010/3/3 akp geek <akpgeek@gmail.com>
Show quoted text
I just made changes to postgresql.conf to make sure the autovacuum is
turned on and I will update you.. Again thanks for your timeRegards
2010/3/3 Devrim GÜNDÜZ <devrim@gunduz.org>
On Wed, 2010-03-03 at 08:32 -0500, akp geek wrote:
Thank you all for the suggestions. I did a vacuum and the size has
gone down drastically. But still it is not the same size as my master.
I am looking into itPlain vacuum does not file system size of relations. It just marks dead
spaces are writable. If you haven't vacuumed for a long time, it
probably means that you have lots of space to be reused.
--
Devrim GÜNDÜZ
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz
On 05/03/10 15:14, akp geek wrote:
Hi All -
I have turned on the auto vacuum on the slave and for some
reason the db is getting bloated up. The master size is only 1G and the
slave is at 9.2GB now. I did cluster on couple of tables also. did any one
run into this situation? Can you please help?
OK - so autovacuum is now running on the slave, but your database keeps
growing anyway.
So - either:
1. You have a long-running transaction blocking the vacuum.
2. Your autovacuum isn't running often enough.
The first step with #1 is to check for idle transactions. Look in the
system view: pg_stat_activity
SELECT * FROM pg_stat_activity;
Is there anything there that started a long time ago (probably marked
IDLE IN TRANSACTION)?
For #2, I would start with seeing what tables are affected, then check
your configuration settings. It might be that autovacuum_naptime is too
large for your workload, or (auto)vacuum_cost_delay is too high.
http://www.postgresql.org/docs/8.4/static/routine-vacuuming.html#AUTOVACUUM
--
Richard Huxton
Archonet Ltd