From: | Douglas J Hunley <doug(at)hunley(dot)homeip(dot)net> |
---|---|
To: | Richard Huxton <dev(at)archonet(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: 7 hrs for a pg_restore? |
Date: | 2008-02-19 19:00:56 |
Message-ID: | 200802191400.56809.doug@hunley.homeip.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Tuesday 19 February 2008 13:13:37 Richard Huxton wrote:
> Douglas J Hunley wrote:
> > I spent a whopping seven hours restoring a database late Fri nite for a
> > client. We stopped the application, ran pg_dump -v -Ft -b -o $db >
> > ~/pre_8.3.tar on the 8.2.x db, and then upgrading the software to 8.3. I
> > then did a pg_restore -v -d $db ./pre_8.3.tar and watched it positively
> > crawl. I'll grant you that it's a 5.1G tar file, but 7 hours seems
> > excessive.
>
> Depends, both on the machine and the database.
>
> What sort of disk i/o are you seeing, what's the cpu(s) doing, and
> what's the restore taking so long over (since you have -v)?
The I/O didn't seem abnormal to me for this customer, so I didn't record it.
It wasn't excessive though. It took the longest on a couple of our highest
volume tables. By far index creation took the longest of the entire process
>
> Oh, and have you tweaked the configuration settings for the restore?
> Lots of work_mem, turn fsync off, that sort of thing.
I didn't tweak anything for the restore specifically. Used the postgresql.conf
as attached in another reply
--
Douglas J Hunley (doug at hunley.homeip.net) - Linux User #174778
http://doug.hunley.homeip.net
One item could not be deleted because it was missing. -- Mac System 7.0b1
error message
From | Date | Subject | |
---|---|---|---|
Next Message | Douglas J Hunley | 2008-02-19 19:08:23 | Re: 7 hrs for a pg_restore? |
Previous Message | Douglas J Hunley | 2008-02-19 18:58:38 | Re: 7 hrs for a pg_restore? |