| From: | Markus Schaber <schabi(at)logix-tt(dot)com> |
|---|---|
| To: | Tim Allen <tim(at)proximity(dot)com(dot)au> |
| Cc: | pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: SAN performance mystery |
| Date: | 2006-06-23 11:56:16 |
| Message-ID: | 449BD6E0.10305@logix-tt.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Markus Schaber | 2006-06-23 12:02:27 | Re: SAN performance mystery |
| Previous Message | luchot | 2006-06-23 10:12:03 | Occupation bloc in pages of table |