FSM and VM file

Started by akp geekabout 16 years ago11 messagesgeneral
Jump to latest
#1akp geek
akpgeek@gmail.com

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

#2Thomas Kellerer
spam_eater@gmx.net
In reply to: akp geek (#1)
Re: FSM and VM file

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

#3Scott Mead
scott.lists@enterprisedb.com
In reply to: akp geek (#1)
Re: FSM and VM file

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

#4akp geek
akpgeek@gmail.com
In reply to: Scott Mead (#3)
Re: FSM and VM file

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

#5Richard Huxton
dev@archonet.com
In reply to: akp geek (#4)
Re: FSM and VM file

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

#6akp geek
akpgeek@gmail.com
In reply to: Richard Huxton (#5)
Re: FSM and VM file

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

#7Richard Huxton
dev@archonet.com
In reply to: akp geek (#6)
Re: FSM and VM file

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

#8Devrim GÜNDÜZ
devrim@gunduz.org
In reply to: akp geek (#6)
Re: FSM and VM file

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

#9akp geek
akpgeek@gmail.com
In reply to: Devrim GÜNDÜZ (#8)
Re: FSM and VM file

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

#10akp geek
akpgeek@gmail.com
In reply to: akp geek (#9)
Re: FSM and VM file

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 time

Regards

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

#11Richard Huxton
dev@archonet.com
In reply to: akp geek (#10)
Re: FSM and VM file

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

http://developer.postgresql.org/pgdocs/postgres/runtime-config-autovacuum.html#RUNTIME-CONFIG-AUTOVACUUM

--
Richard Huxton
Archonet Ltd