Re: vacuum locking

From: Manfred Koizar <mkoi-pg(at)aon(dot)at>
To: Rob Nagler <nagler(at)bivio(dot)biz>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: vacuum locking
Date: 2003-10-17 17:41:56
Message-ID: cm90pvsbml6qdpe9el3qm66ogj7cpdk5ar@email.aon.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Fri, 17 Oct 2003 09:52:26 -0600, Rob Nagler <nagler(at)bivio(dot)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

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Rob Nagler 2003-10-17 23:11:59 Re: vacuum locking
Previous Message Murthy Kambhampaty 2003-10-17 17:33:36 Re: [PERFORM] backup/restore - another area.