pg.ddx.io pgsql-performance@postgresql.org mailing list archive
help / color / mirror / Atom feedpg_dump issue
6+ messages / 3 participants
[nested] [flat]
* pg_dump issue
@ 2006-05-30 14:31 mcelroy, tim <tim.mcelroy@bostonstock.com>
0 siblings, 2 replies; 6+ messages in thread
From: mcelroy, tim @ 2006-05-30 14:31 UTC (permalink / raw)
To: pgsql-performance
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 one machine
than on the other. I back up five (5) databases totaling 8.6GB in size. On
Prod001 the backups take app. 7 minutes, on Prod002 the backups take app. 26
minutes! Quite a discrepancy. I checked myself than checked with our
Engineering staff and have been assured that the machines are identical
hardware wise, CPU, disk, etc.
Question; has anyone run into a similar issue? Here is the command I use
for the nightly backup on both machines:
pg_dump -F c -f $DB.backup.$DATE $DB
Kind of scratching my head on this one....
Thank you,
Tim McElroy
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: pg_dump issue
@ 2006-05-30 15:15 Tom Lane <tgl@sss.pgh.pa.us>
parent: mcelroy, tim <tim.mcelroy@bostonstock.com>
1 sibling, 0 replies; 6+ messages in thread
From: Tom Lane @ 2006-05-30 15:15 UTC (permalink / raw)
To: mcelroy, tim <tim.mcelroy@bostonstock.com>; +Cc: pgsql-performance
"mcelroy, tim" <tim.mcelroy@bostonstock.com> 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 on one machine
> than on the other. I back up five (5) databases totaling 8.6GB in size. On
> Prod001 the backups take app. 7 minutes, on Prod002 the backups take app. 26
> minutes! Quite a discrepancy.
Are the resulting backup files identical? Chasing down the reasons for
any diffs might yield some enlightenment.
One idea that comes to mind is that Prod002 is having performance
problems due to table bloat (maybe a missing vacuum cron job or
some such). A quick "du" on the two $PGDATA directories to check
for significant size differences would reveal this if so.
regards, tom lane
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: pg_dump issue
@ 2006-05-30 15:33 mcelroy, tim <tim.mcelroy@bostonstock.com>
0 siblings, 1 reply; 6+ messages in thread
From: mcelroy, tim @ 2006-05-30 15:33 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-performance
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
they're pretty much the same, one would think the smaller one should be
faster. Yes, the backup files are identical in size. BTW - this is
postgres 8.0.1. Stuck at this due to "that is the latest postgresql version
certified by our vendor's application".
I'm hoping the Engineering staff can find something system related as I
doubted and still doubt that it's a postgres issue.
Tim
-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: Tuesday, May 30, 2006 11:16 AM
To: mcelroy, tim
Cc: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] pg_dump issue
"mcelroy, tim" <tim.mcelroy@bostonstock.com> 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 on one
machine
> than on the other. I back up five (5) databases totaling 8.6GB in size.
On
> Prod001 the backups take app. 7 minutes, on Prod002 the backups take app.
26
> minutes! Quite a discrepancy.
Are the resulting backup files identical? Chasing down the reasons for
any diffs might yield some enlightenment.
One idea that comes to mind is that Prod002 is having performance
problems due to table bloat (maybe a missing vacuum cron job or
some such). A quick "du" on the two $PGDATA directories to check
for significant size differences would reveal this if so.
regards, tom lane
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: pg_dump issue
@ 2006-05-30 16:20 Tom Lane <tgl@sss.pgh.pa.us>
parent: mcelroy, tim <tim.mcelroy@bostonstock.com>
0 siblings, 0 replies; 6+ messages in thread
From: Tom Lane @ 2006-05-30 16:20 UTC (permalink / raw)
To: mcelroy, tim <tim.mcelroy@bostonstock.com>; +Cc: pgsql-performance
"mcelroy, tim" <tim.mcelroy@bostonstock.com> 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
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: pg_dump issue
@ 2006-05-30 17:12 mcelroy, tim <tim.mcelroy@bostonstock.com>
0 siblings, 0 replies; 6+ messages in thread
From: mcelroy, tim @ 2006-05-30 17:12 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-performance
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@sss.pgh.pa.us]
Sent: Tuesday, May 30, 2006 12:20 PM
To: mcelroy, tim
Cc: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] pg_dump issue
"mcelroy, tim" <tim.mcelroy@bostonstock.com> 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
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: pg_dump issue
@ 2006-06-02 12:17 Evgeny Gridasov <eugene@i-free.ru>
parent: mcelroy, tim <tim.mcelroy@bostonstock.com>
1 sibling, 0 replies; 6+ messages in thread
From: Evgeny Gridasov @ 2006-06-02 12:17 UTC (permalink / raw)
To: pgsql-performance
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" <tim.mcelroy@bostonstock.com> wrote:
> 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 one machine
> than on the other. I back up five (5) databases totaling 8.6GB in size. On
> Prod001 the backups take app. 7 minutes, on Prod002 the backups take app. 26
> minutes! Quite a discrepancy. I checked myself than checked with our
> Engineering staff and have been assured that the machines are identical
> hardware wise, CPU, disk, etc.
>
> Question; has anyone run into a similar issue? Here is the command I use
> for the nightly backup on both machines:
>
> pg_dump -F c -f $DB.backup.$DATE $DB
>
> Kind of scratching my head on this one....
>
> Thank you,
> Tim McElroy
>
>
--
Evgeny Gridasov
Software Engineer
I-Free, Russia
^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2006-06-02 12:17 UTC | newest]
Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2006-05-30 14:31 pg_dump issue mcelroy, tim <tim.mcelroy@bostonstock.com>
2006-05-30 15:15 ` Tom Lane <tgl@sss.pgh.pa.us>
2006-06-02 12:17 ` Evgeny Gridasov <eugene@i-free.ru>
2006-05-30 15:33 Re: pg_dump issue mcelroy, tim <tim.mcelroy@bostonstock.com>
2006-05-30 16:20 ` Tom Lane <tgl@sss.pgh.pa.us>
2006-05-30 17:12 Re: pg_dump issue mcelroy, tim <tim.mcelroy@bostonstock.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox