Okay, I collated the three replies I got below for ease in replying. I vacuum full analyze and reindexdb approximately once a month, but I use pg_autovacuum as a matter of ongoing maintenance, and it seems to hit equilibrium pretty well and seems to prevent bloat. The last time I checked a vacuum analyze verbose, I had plenty of FSM to spare. The data grows, but it doesn't seem to grow so quickly that I'd already be out of FSM space. I actually run pg_dump from a remote machine, so I/O contention on the partition with $PGDATA shouldn't be an issue. And here is the actual command: pg_dump -h <host> -F c <database> > <dumpfile> Pretty basic, although it is compressing. As far as I can tell, the postmaster handling the dump request takes up quite a bit of CPU, but not itself to the point where the database should be unusable under ordinary circumstances. E.g., when a query/backend eats up that much CPU, it doesn't prevent further access. I'm suspicious more of something involving locks than of CPU. Oh, and one other small(ish) detail: the dumping client is using a 7.4.8 installation, whereas the server itself is 7.4.6. -tfo -- Thomas F. O'Connell Co-Founder, Information Architect Sitening, LLC Strategic Open Source: Open Your i™ 110 30th Avenue North, Suite 6 Nashville, TN 37203-6320 615-260-0005
|
- Re: [GENERAL] pg_dump in a production environment Thomas F. O'Connell
- Re: [GENERAL] pg_dump in a production environment Chris Kratz
- Re: [GENERAL] pg_dump in a production environ... Scott Marlowe
- Re: [GENERAL] pg_dump in a production env... Chris Kratz
- Re: [GENERAL] pg_dump in a production environment Thomas F. O'Connell
- Re: [GENERAL] pg_dump in a production environ... Scott Marlowe
- Re: [GENERAL] pg_dump in a production environment Tom Lane
- Re: [GENERAL] pg_dump in a production environ... Thomas F. O'Connell
- Re: [GENERAL] (Ideas) pg_dump in a production... Russell Smith