Re: max_fsm_pages question

Поиск
Список
Период
Сортировка
От Michael Monnerie
Тема Re: max_fsm_pages question
Дата
Msg-id 201001251540.19636@zmi.at
обсуждение исходный текст
Ответ на Re: max_fsm_pages question  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Ответы Re: max_fsm_pages question  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Список pgsql-admin
On Montag, 25. Januar 2010 Kevin Grittner wrote:
> Michael Monnerie  wrote:
> > why did postgres suddenly decide to remove the old cruft suddenly?
>
> Have you read through this yet?:
>
> http://www.postgresql.org/docs/8.3/interactive/runtime-config-resourc
> e.html#RUNTIME-CONFIG-RESOURCE-FSM

Yes I did.

> > Autovacuum is on, the nightly backups do an extra "vacuum analyze",
> > and once a week a CLUSTER is done for the big tables.
>
> You should probably make that a "vacuum analyze verbose" to get a
> good idea of where you should set max_fsm_pages, and to look for
> where you are accumumlating free space to track.

That's why I find it strange. I always log the VACUUM VERBOSE ANALYZE
command, it is run nightly:
INFO:  free space map contains 21517 pages in 107 relations
DETAIL:  A total of 22912 page slots are in use (including overhead).
22912 page slots are required to track all free space.
Current limits are:  150000 page slots, 1000 relations, using 984 kB.

So, as there was that one relation that was bloatet - how could it be?
Autovaccuum, nightly vacuum analyze, weekly cluster - and still a heavy
bloated toast* something. I must do something wrong.

--
mit freundlichen Grüssen,
Michael Monnerie, Ing. BSc

it-management Internet Services
http://it-management.at
Tel: 0660 / 415 65 31

// Wir haben zwei Häuser zu verkaufen:
// http://zmi.at/langegg/
// http://willhaben.at/iad/realestate/object?adId=15923011

Вложения

В списке pgsql-admin по дате отправления:

Предыдущее
От: "Kevin Grittner"
Дата:
Сообщение: Re: max_fsm_pages question
Следующее
От: "Kevin Grittner"
Дата:
Сообщение: Re: max_fsm_pages question