Re: [PERFORM] pg_dump issue

2006-06-03 Thread Evgeny Gridasov
try to dump-restore your 'slow' database, this might help if your db or filesystem gets too fragmented. On Tue, 30 May 2006 10:31:08 -0400 mcelroy, tim [EMAIL PROTECTED] wrote: Good morning, I have identical postgres installations running on identical machines. Dual Core AMD Opteron(tm)

[PERFORM] pg_dump issue

2006-05-30 Thread mcelroy, tim
Title: pg_dump issue Good morning, I have identical postgres installations running on identical machines. Dual Core AMD Opteron(tm) Processor 870 , 16GB RAM, Red Hat Linux 3.2.3-20 and 120GB worth of disk space on two drives. Recently, I have noticed that my nightly backups take longer on

Re: [PERFORM] pg_dump issue

2006-05-30 Thread Tom Lane
mcelroy, tim [EMAIL PROTECTED] writes: I have identical postgres installations running on identical machines. Dual Core AMD Opteron(tm) Processor 870 , 16GB RAM, Red Hat Linux 3.2.3-20 and 120GB worth of disk space on two drives. Recently, I have noticed that my nightly backups take longer

Re: [PERFORM] pg_dump issue

2006-05-30 Thread mcelroy, tim
Title: RE: [PERFORM] pg_dump issue Thanks Tom. I have scheduled vacuums as follows and all have run without error. Mon - Thu after-hours: vacuumdb -z -e -a -v On Fridays I add the -f option vacuumdb -z -e -a -v -f The du . -h in $PGDATA showed PROD001 at 9.1G and Prod0002 at 8.8G so

Re: [PERFORM] pg_dump issue

2006-05-30 Thread mcelroy, tim
Title: RE: [PERFORM] pg_dump issue I did carry it down to the subdirectory level but only included the total for brevity. I'll paste the complete readout at the end of the email. I'll try the vmstat 1 as you suggest next time the backups run. If the Eng staff finds anything I'll post