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 the results and maybe save someone else some grief if they have the same issue. Thanks again for your input Tom.
Tim
PROD001 PROD002
220K ./global[PARA]4.0K ./pg_xlog/archive_status[PARA]529M ./pg_xlog[PARA]36K ./pg_clog[PARA]256K ./pg_subtrans[PARA]4.0K ./base/1/pgsql_tmp[PARA]4.8M ./base/1[PARA]4.8M ./base/17229[PARA]4.0K ./base/62878500/pgsql_tmp[PARA]4.8M ./base/62878500[PARA]5.5M ./base/1152695[PARA]4.0K ./base/67708567/pgsql_tmp[PARA]1.6G ./base/67708567[PARA]12K ./base/1157024/pgsql_tmp[PARA]6.3G ./base/1157024[PARA]4.0K ./base/1159370/pgsql_tmp[PARA]543M ./base/1159370[PARA]4.0K ./base/1157190/pgsql_tmp[PARA]164M ./base/1157190[PARA]4.0K ./base/1621391/pgsql_tmp[PARA]81M ./base/1621391[PARA]8.6G ./base[PARA]4.0K ./pg_tblspc[PARA]604K ./pg_log[PARA]9.1G . 220K ./global[PARA]4.0K ./pg_xlog/archive_status[PARA]529M ./pg_xlog[PARA]136K ./pg_clog[PARA]208K ./pg_subtrans[PARA]4.0K ./base/1/pgsql_tmp[PARA]4.9M ./base/1[PARA]4.8M ./base/17229[PARA]5.3M ./base/1274937[PARA]4.0K ./base/64257611/pgsql_tmp[PARA]1.6G ./base/64257611[PARA]4.0K ./base/71683200/pgsql_tmp[PARA]6.1G ./base/71683200[PARA]4.0K ./base/1281929/pgsql_tmp[PARA]478M ./base/1281929[PARA]4.0K ./base/58579022/pgsql_tmp[PARA]154M ./base/58579022[PARA]81M ./base/1773916[PARA]4.0K ./base/55667447/pgsql_tmp[PARA]4.8M ./base/55667447[PARA]8.3G ./base[PARA]4.0K ./pg_tblspc[PARA]588K ./pg_log[PARA]8.8G .
-----Original Message-----
From: Tom Lane [mailto:tgl@xxxxxxxxxxxxx]
Sent: Tuesday, May 30, 2006 12:20 PM
To: mcelroy, tim
Cc: pgsql-performance@xxxxxxxxxxxxxx
Subject: Re: [PERFORM] pg_dump issue
"mcelroy, tim" <tim.mcelroy@xxxxxxxxxxxxxxx> writes:
> The du . -h in $PGDATA showed PROD001 at 9.1G and Prod0002 at 8.8G so
> they're pretty much the same, one would think the smaller one should be
> faster. Yes, the backup files are identical in size.
Hmph. You should carry the "du" analysis down to the subdirectory
level, eg make sure that it's not a case of lots of pg_xlog bloat
balancing out bloat in a different area on the other system. But I
suspect you won't find anything.
> I'm hoping the Engineering staff can find something system related as I
> doubted and still doubt that it's a postgres issue.
I tend to agree. You might try watching "vmstat 1" output while taking
the dumps, so you could at least get a clue whether the problem is CPU
or I/O related ...
regards, tom lane
