Re: SAN performance mystery

Поиск
Список
Период
Сортировка
От Markus Schaber
Тема Re: SAN performance mystery
Дата
Msg-id 449BD6E0.10305@logix-tt.com
обсуждение исходный текст
Ответ на SAN performance mystery  (Tim Allen <tim@proximity.com.au>)
Ответы Re: SAN performance mystery
Список pgsql-performance
Hi, Tim,

Tim Allen wrote:
> One thing that has been
> apparent is that autovacuum has not been able to keep the database
> sufficiently tamed. A pg_dump/pg_restore cycle reduced the total
> database size from 81G to 36G.

Two first shots:

- Increase your free_space_map settings, until (auto)vacuum does not
warn about a too small FSM setting any more

- Tune autovacuum to run more often, possibly with a higher delay
setting to lower the load.

If you still have the original database around,

> Performing the restore took about 23 hours.

Try to put the WAL on another spindle, and increase the WAL size /
checkpoint segments.

When most of the restore time was spent in index creation, increase the
sort mem / maintainance work mem settings.


HTH,
Markus

--
Markus Schaber | Logical Tracking&Tracing International AG
Dipl. Inf.     | Software Development GIS

Fight against software patents in EU! www.ffii.org www.nosoftwarepatents.org

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

Предыдущее
От: luchot
Дата:
Сообщение: Occupation bloc in pages of table
Следующее
От: Markus Schaber
Дата:
Сообщение: Re: SAN performance mystery