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 по дате отправления: