Re: vacuum locking - Mailing list pgsql-performance

From Manfred Koizar
Subject Re: vacuum locking
Date
Msg-id cm90pvsbml6qdpe9el3qm66ogj7cpdk5ar@email.aon.at
Whole thread Raw
In response to Re: vacuum locking  (Rob Nagler <nagler@bivio.biz>)
Responses Re: vacuum locking  (Rob Nagler <nagler@bivio.biz>)
List pgsql-performance
On Fri, 17 Oct 2003 09:52:26 -0600, Rob Nagler <nagler@bivio.biz>
wrote:
>INFO:  Removed 8368 tuples in 427 pages.
>        CPU 0.06s/0.04u sec elapsed 1.54 sec.
>INFO:  Pages 24675: Changed 195, Empty 0; Tup 1031519: Vac 8368, Keep 254, UnUsed 1739.
>        Total CPU 2.92s/2.58u sec elapsed 65.35 sec.
>
>INFO:  Removed 232 tuples in 108 pages.
>        CPU 0.01s/0.02u sec elapsed 0.27 sec.
>INFO:  Pages 74836: Changed 157, Empty 0; Tup 4716475: Vac 232, Keep 11, UnUsed
>641.
>        Total CPU 10.19s/6.03u sec elapsed 261.44 sec.

The low UnUsed numbers indicate that FSM is working fine.

>Assuming I vacuum every 15 minutes, it would seem like max_fsm_pages
>should be 1000, because that's about what was reclaimed.  The default
>is 10000.  Do I need to change this?

ISTM you are VACCUMing too aggressively.  You are reclaiming less than
1% and 0.005%, respectively, of tuples.  I would increase FSM settings
to ca. 1000 fsm_relations, 100000 fsm_pages and VACUUM *less* often,
say every two hours or so.

... or configure autovacuum to VACUUM a table when it has 10% dead
tuples.

Servus
 Manfred

pgsql-performance by date:

Previous
From: Josh Berkus
Date:
Subject: Re: vacuum locking
Next
From: Murthy Kambhampaty
Date:
Subject: Re: [ADMIN] backup/restore - another area.