Re: Excessive growth of pg_attribute and other system tables

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Excessive growth of pg_attribute and other system tables
Дата
Msg-id 29316.1111109568@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Excessive growth of pg_attribute and other system tables  (Steve Crawford <scrawford@pinpointresearch.com>)
Ответы Re: Excessive growth of pg_attribute and other system tables  ("Matthew T. O'Connor" <matthew@zeut.net>)
Список pgsql-admin
Steve Crawford <scrawford@pinpointresearch.com> writes:
> On Thursday 17 March 2005 3:51 pm, Tom Lane wrote:
>> Do you have the FSM settings set large enough to account for all
>> the free space?

> max_fsm_pages = 20000
> max_fsm_relations = 1000

That doesn't sound like nearly enough pages for a 2G database.
20000 * 8K = 160MB, so if more than 10% of the pages in your DB
are dirty you are going to be leaking free space.  You probably
want max_fsm_pages up around 250,000.

> I just poked through the cluster. I have 6 user databases plus
> template0 and template1. Total tables in the cluster has reached
> slightly over 1,000 user tables plus all the system tables in the 8
> databases. Does this indicate that I need to increase
> max_fsm_relations to greater than the total number of tables in the
> cluster?

That would be a good plan too.

> pg_autovacuum is from 7.4.6 release and is showing periodic vacuums of
> the problem tables. I thought that bug was in some release prior to
> 7.4.6. Does the bug allow it to show a vacuum taking place but not do
> it?

I don't recall the details of the changes; you could look at the CVS
logs to see what got fixed when.  But in any case I think we see the
main problem: max_fsm_pages too small.

            regards, tom lane

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

Предыдущее
От: Steve Crawford
Дата:
Сообщение: Re: Excessive growth of pg_attribute and other system tables
Следующее
От: Christopher Browne
Дата:
Сообщение: Re: Excessive growth of pg_attribute and other system tables