From: | Andy Colson <andy(at)squeakycode(dot)net> |
---|---|
To: | contato(at)alexanderburbello(dot)com(dot)br |
Cc: | Alexander Burbello <burbello(at)yahoo(dot)com(dot)br>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Restore db |
Date: | 2011-11-14 01:22:31 |
Message-ID: | 4EC06D57.8020402@squeakycode.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin pgsql-general |
On 11/13/2011 06:09 PM, Alexander Burbello wrote:
> Hi folks,
>
> My server has a daily routine to import a dump file, however its taking long time to finish it.
> The original db has around 200 MB and takes 3~4 minutes to export (there are many blob fields), however it takes 4 hours to import using pg_restore.
>
> What can I do to tune this database to speed up this restore??
>
> My current db parameters are:
> shared_buffers = 256MB
> maintenance_work_mem = 32MB
>
> Any suggestion is very welcome.
> Thank you.
> Alex
Are you doing this over a network?
If you watch it restore with vmstat (or top) are you IO bound? If so, temporarily turn off fsync, restore the db, then turn it back on.
something like:
autovacuum = off
fsync = off
synchronous_commit = off
full_page_writes = off
bgwriter_lru_maxpages = 0
On the other hand, if you are cpu bound, use the multi-core-restore-option -j.
Or use both.
> My current db parameters are:
> shared_buffers = 256MB
> maintenance_work_mem = 32MB
This is useless information without knowing anything about your computer. If you have 512 Meg of ram its a lot different than if you have 32 Gig.
-Andy
From | Date | Subject | |
---|---|---|---|
Next Message | Manoj K P | 2011-11-14 09:54:52 | Database corruption |
Previous Message | Ondrej Ivanič | 2011-11-14 00:43:57 | Re: Restore db |
From | Date | Subject | |
---|---|---|---|
Next Message | Craig Ringer | 2011-11-14 01:35:51 | Re: Help with Stack Builder |
Previous Message | Ondrej Ivanič | 2011-11-14 00:43:57 | Re: Restore db |