Saranya Sivakumar | 6 Aug 18:54 2006
Picon

7.3.2 pg_restore very slow

Hi All,
 
I am trying to back up a full copy of one of our databases (14G) and restore it on another server. Both databases run 7.3.2 version. Though the restore completed successfully, it took 9 hours for the process to complete. The destination server runs Fedora Core 3 with 512 MB RAM and has 1 processor.  I have also deferred referential intergrity checks during the restore. I tried to tune some parameters in the config file, but it still takes 9 hours.
 
I have tried this same procedure to restore a full copy, but using 8.1(pg_dump and pg_restore) on a different server and that process took only 2 hours for the same database. But we are unable to migrate to 8.1 at this point and stuck with 7.3.2.
 
I use a script to dump/restore. I can send the same if that information is needed.
 
Please give me some pointers on what else I should be looking at to reduce the restore time using 7.3.2 version.
 
Thanks,
Sincerely,
Saranya Sivakumar
 
 
 
 
 

Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countries) for 2¢/min or less.
Saranya Sivakumar | 7 Aug 17:35 2006
Picon

Re: [PERFORM] 7.3.2 pg_restore very slow

Hi Richard,
 
Thank you very much for the suggestions. As I said, we are stuck with 7.3.2 version for now. We have a Upgrade Project in place, but this backup is something we have to do immediately (we do not have enough time to test our application with 7.3.15 :( )
 
The checkpoint segments occur every 1.15 minutes with the default setting.
I tried tuning some parameters in the conf file, which took 4.5 hours for the restore.
 
sort_mem = 40960
shared_buffers = 3000
#checkpoint_segments = 3  (default)
#fsync = true    --I will disable this and try
 
We can afford to have a downtime of only 1 to 1.5 hours.
I am going to increase the shared_buffers, sort_mem and disable fysnc as suggested by you, and try the restore process again.
 
I would appreciate any other suggestions/advice in this regard.
 
Thanks,
Saranya
 


Richard Huxton <dev <at> archonet.com> wrote:
Saranya Sivakumar wrote:
> Hi All,
>
> I am trying to back up a full copy of one of our databases (14G) and
> restore it on another server. Both databases run 7.3.2 version.
> Though the restore completed successfully, it took 9 hours for the
> process to complete. The destination server runs Fedora Core 3 with
> 512 MB RAM and has 1 processor. I have also deferred referential
> intergrity checks during the restore. I tried to tune some parameters
> in the config file, but it still takes 9 hours.

Firstly, you should upgrade to the most recent version of 7.3.x (7.3.15)
- that's a *lot* of bug-fixes you are missing

Then, I would temporarily disable fsync and increase sort_mem and
checkpoint_segments. What you're trying to do is make a single process
run as fast as possible, so allow it to grab more resources than you
normally would.

--
Richard Huxton
Archonet Ltd

See the all-new, redesigned Yahoo.com. Check it out.
Saranya Sivakumar | 7 Aug 18:08 2006
Picon

Re: [PERFORM] 7.3.2 pg_restore very slow

Hi All,
 
I tried to set shared_buffers= 10000, turned off fsync and reload the config file.
But I got the following error:
 
IpcMemoryCreate: shmget(key=5432001, size=85450752, 03600) failed: Invalid argument
This error usually means that PostgreSQL's request for a shared memory
segment exceeded your kernel's SHMMAX parameter.  You can either
reduce the request size or reconfigure the kernel with larger SHMMAX.
To reduce the request size (currently 85450752 bytes), reduce
PostgreSQL's shared_buffers parameter (currently 10000) and/or
its max_connections parameter (currently 128).
If the request size is already small, it's possible that it is less than
your kernel's SHMMIN parameter, in which case raising the request size or
reconfiguring SHMMIN is called for.
The total RAM available on this machine is 512MB.
 
I am not sure how to set these parameters SHMMAX and SHMMIN.
Any help/advice would be greatly appreciated.
 
Thanks,
Saranya

Richard Huxton <dev <at> archonet.com> wrote:
Saranya Sivakumar wrote:
> Hi All,
>
> I am trying to back up a full copy of one of our databases (14G) and
> restore it on another server. Both databases run 7.3.2 version.
> Though the restore completed successfully, it took 9 hours for the
> process to complete. The destination server runs Fedora Core 3 with
> 512 MB RAM and has 1 processor. I have also deferred referential
> intergrity checks during the restore. I tried to tune some parameters
> in the config file, but it still takes 9 hours.

Firstly, you should upgrade to the most recent version of 7.3.x (7.3.15)
- that's a *lot* of bug-fixes you are missing

Then, I would temporarily disable fsync and increase sort_mem and
checkpoint_segments. What you're trying to do is make a single process
run as fast as possible, so allow it to grab more resources than you
normally would.

--
Richard Huxton
Archonet Ltd

Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail Beta.
Richard Broersma Jr | 7 Aug 18:17 2006
Picon

Re: [PERFORM] 7.3.2 pg_restore very slow

>   IpcMemoryCreate: shmget(key=5432001, size=85450752, 03600) failed: Invalid argument
>   This error usually means that PostgreSQL's request for a shared memory
> segment exceeded your kernel's SHMMAX parameter.  You can either
> reduce the request size or reconfigure the kernel with larger SHMMAX.
> To reduce the request size (currently 85450752 bytes), reduce
> PostgreSQL's shared_buffers parameter (currently 10000) and/or
> its max_connections parameter (currently 128).
>   If the request size is already small, it's possible that it is less than
> your kernel's SHMMIN parameter, in which case raising the request size or
> reconfiguring SHMMIN is called for.

if you cat /proc/sys/kernel/shmmax
it will tell you what it is set to. It needs to be at least "85450752". The size that Postgresql
is trying to grab.

also shmall may need to be adjusted also.

>   The total RAM available on this machine is 512MB. 
>    
>   I am not sure how to set these parameters SHMMAX and SHMMIN. 
>   Any help/advice would be greatly appreciated.

http://www.postgresql.org/docs/8.1/interactive/kernel-resources.html
This will help you to set the kernel parameters.

Regards,

Richard Broersma Jr.

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
       subscribe-nomail command to majordomo <at> postgresql.org so that your
       message can get through to the mailing list cleanly

Saranya Sivakumar | 7 Aug 19:28 2006
Picon

Re: [PERFORM] 7.3.2 pg_restore very slow

Hi Richard,
 
Thank you very much for the information. The SHMMAX was set to 33554432, and that's why it failed to start the postmaster. Thanks for the link to the kernel resources article. I guess changing these parameters would require recompiling the kernel.
 
Is there any work around without changing these parameters to make maximum use of RAM?
 
We got a new server now with 2GB RAM, but it also has the same value for SHMMAX.
 
And I am trying the restore with the following conf
sort_mem = 40960  (changed from 1024)

shared_buffers = 3000 (changed from 64)

max_connections = 128 (changed from 32)
 
Thanks,
Saranya
 
 
 

Richard Broersma Jr <rabroersma <at> yahoo.com> wrote:
> IpcMemoryCreate: shmget(key=5432001, size=85450752, 03600) failed: Invalid argument
> This error usually means that PostgreSQL's request for a shared memory
> segment exceeded your kernel's SHMMAX parameter. You can either
> reduce the request size or reconfigure the kernel with larger SHMMAX.
> To reduce the request size (currently 85450752 bytes), reduce
> PostgreSQL's shared_buffers parameter (currently 10000) and/or
> its max_connections parameter (currently 128).
> If the request size is already small, it's possible that it is less than
> your kernel's SHMMIN parameter, in which case raising the request size or
> reconfiguring SHMMIN is called for.

if you cat /proc/sys/kernel/shmmax
it will tell you what it is set to. It needs to be at least "85450752". The size that Postgresql
is trying to grab.

also shmall may need to be adjusted also.

> The total RAM available on this machine is 512MB.
>
> I am not sure how to set these parameters SHMMAX and SHMMIN.
> Any help/advice would be greatly appreciated.

http://www.postgresql.org/docs/8.1/interactive/kernel-resources.html
This will help you to set the kernel parameters.

Regards,

Richard Broersma Jr.


Groups are talking. We´re listening. Check out the handy changes to Yahoo! Groups.
Richard Broersma Jr | 7 Aug 21:18 2006
Picon

Re: [PERFORM] 7.3.2 pg_restore very slow

>   Thank you very much for the information. The SHMMAX was set to 33554432, and that's why it
> failed to start the postmaster. Thanks for the link to the kernel resources article. I guess
> changing these parameters would require recompiling the kernel. 
>    
>   Is there any work around without changing these parameters to make maximum use of RAM?
>    
>   We got a new server now with 2GB RAM, but it also has the same value for SHMMAX.
>    
>   And I am trying the restore with the following conf
>   sort_mem = 40960  (changed from 1024)
>   shared_buffers = 3000 (changed from 64)
>     max_connections = 128 (changed from 32)

This is one of the best links that I can give you in addition to the Postgresql Kernel resource
link.
http://www.powerpostgresql.com/PerfList

I am pretty much a beginner at resource tuning also.  In fact, after googling for sources that
describe how to tune kernel parameters, the postgresql documents remains the best documents I've
found so far.

I would be interested if anyone else on the list knows of any resources or books that have an in
depth discussion on methods/strategies to tune kernel parameters to maximized usage of system
resources and at the same time allow for harmonious sharing between various programs/services.

Regards,

Richard Broersma Jr.

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
       subscribe-nomail command to majordomo <at> postgresql.org so that your
       message can get through to the mailing list cleanly

Saranya Sivakumar | 7 Aug 22:07 2006
Picon

Re: [PERFORM] 7.3.2 pg_restore very slow

Hi All,
 
Thanks Richard for the additional link. The information is very useful.
 
The restore completed successfully in 2.5 hours in the new 2GB box, with the same configuration parameters. I think if I can tweak the parameters a little more, I should be able to get it down to the 1 hr down time  that we can afford.
 
Thanks again for all the help.
 
Sincerely,
Saranya

Richard Broersma Jr <rabroersma <at> yahoo.com> wrote:
> Thank you very much for the information. The SHMMAX was set to 33554432, and that's why it
> failed to start the postmaster. Thanks for the link to the kernel resources article. I guess
> changing these parameters would require recompiling the kernel.
>
> Is there any work around without changing these parameters to make maximum use of RAM?
>
> We got a new server now with 2GB RAM, but it also has the same value for SHMMAX.
>
> And I am trying the restore with the following conf
> sort_mem = 40960 (changed from 1024)
> shared_buffers = 3000 (changed from 64)
> max_connections = 128 (changed from 32)

This is one of the best links that I can give you in addition to the Postgresql Kernel resource
link.
http://www.powerpostgresql.com/PerfList

I am pretty much a beginner at resource tuning also. In fact, after googling for sources that
describe how to tune kernel parameters, the postgresql documents remains the best documents I've
found so far.

I would be interested if anyone else on the list knows of any resources or books that have an in
depth discussion on methods/strategies to tune kernel parameters to maximized usage of system
resources and at the same time allow for harmonious sharing between various programs/services.

Regards,

Richard Broersma Jr.

Want to be your own boss? Learn how on Yahoo! Small Business.
Jim C. Nasby | 10 Aug 00:26 2006

Re: BUG #2567: High IOWAIT

This isn't a bug; moving to pgsql-performance.

On Tue, Aug 08, 2006 at 08:42:02AM +0000, kumarselvan wrote:
> i have installed the postgres as mentioned in the Install file. it is a 4
> cpu 8 GB Ram Machine installed with Linux Enterprise version 3. when i am
> running a load which will perfrom 40 inserts persecond on 2 tables and 10
> updates per 10seconds on differnt table IOWait on avg going upto 70% due to
> which i am not able to increase the load. Is there is any other way to
> install the postgres on multiprocessor machine.. can any one help me on
> this...

You haven't given us nearly enough information. What kind of hardware is
this? RAID? What changes have you made to postgresql.conf?
--

-- 
Jim C. Nasby, Sr. Engineering Consultant      jnasby <at> pervasive.com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
       subscribe-nomail command to majordomo <at> postgresql.org so that your
       message can get through to the mailing list cleanly

Richard Huxton | 7 Aug 11:55 2006

Re: [PERFORM] 7.3.2 pg_restore very slow

Saranya Sivakumar wrote:
> Hi All,
> 
> I am trying to back up a full copy of one of our databases (14G) and
> restore it on another server. Both databases run 7.3.2 version.
> Though the restore completed successfully, it took 9 hours for the
> process to complete. The destination server runs Fedora Core 3 with
> 512 MB RAM and has 1 processor.  I have also deferred referential
> intergrity checks during the restore. I tried to tune some parameters
> in the config file, but it still takes 9 hours.

Firstly, you should upgrade to the most recent version of 7.3.x (7.3.15) 
- that's a *lot* of bug-fixes you are missing

Then, I would temporarily disable fsync and increase sort_mem and 
checkpoint_segments. What you're trying to do is make a single process 
run as fast as possible, so allow it to grab more resources than you 
normally would.

--

-- 
   Richard Huxton
   Archonet Ltd

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
       subscribe-nomail command to majordomo <at> postgresql.org so that your
       message can get through to the mailing list cleanly

Markus Schaber | 7 Aug 20:25 2006

Re: [PERFORM] 7.3.2 pg_restore very slow

Hi, Saranya,

Saranya Sivakumar wrote:
> Thank you very much for the information. The SHMMAX was set to 33554432,
> and that's why it failed to start the postmaster. Thanks for the link to
> the kernel resources article. I guess changing these parameters would
> require recompiling the kernel.

As stated on the
http://www.postgresql.org/docs/8.1/interactive/kernel-resources.html
page, those values can be changed via sysctl or echoing values into
/proc, under linux at least.

HTH,
Markus

--

-- 
Markus Schaber | Logical Tracking&Tracing International AG
Dipl. Inf.     | Software Development GIS

Fight against software patents in EU! www.ffii.org www.nosoftwarepatents.org

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

               http://www.postgresql.org/docs/faq


Gmane