probkup speed

Posted by bremmeyr on 23-Jun-2015 12:54

What can be done to speed up probkup? There really aren't and options with parameters that I see. In my case I am running an online backup with the resulting file is on to a hard drive that is not the same drive the DB is on.  

Progress OpenEdge 10.2B 00, OS Windows server 2008 R2. 64 bit 8 GB ram. 

All Replies

Posted by Paul Koufalis on 23-Jun-2015 13:04

Get a faster I/O subsystem.

Use -com to avoid backing up empty blocks.

If your BI is huge relative to your total DB size then the fact that you have to back that up is also increasing the total backup time. Upgrade to 11.4 where only the active portions of the BI are backed up (feature was bugged in earlier 11.x) or consider truncating your BI occasionally then regrowing to its natural size.

Probkup doesn't do much more than read a block from one file and write it to another so the speed is almost exclusively limited by your disk I/O bandwidth.

Posted by TheMadDBA on 23-Jun-2015 13:21

Everything that Paul said.... plus

0) At least apply the service packs for 10.2B (unless that was a typo). Pretty sure there were some changes for probkup in the early service packs of 10.2B.

1) There is a specific issue with 10.2B and Windows 2008. Basically remove the old probkup files before you run probkup.     knowledgebase.progress.com/.../000029180

2) Enable AI and use the hot copy for backups,restores, to test etc. Plus you will have AI running....

3) You can try using private buffers -Bp but I have only seen improvements when the DB is really,really,really busy during the probkup time. Meaning sustained 100K record reads per second.

Posted by gus on 23-Jun-2015 13:22

> On Jun 23, 2015, at 1:54 PM, bremmeyr wrote:
>
>[collapse] From: bremmeyr
> Post: probkup speed
> Posted in: Forum
> Link: https://community.progress.com/community_groups/openedge_rdbms/f/18/t/18779.aspx
>
> What can be done to speed up probkup? There really aren't and options with parameters that I see. In my case I am running an online backup with the resulting file is on to a hard drive that is not the same drive the DB is on.
> Progress OpenEdge 10.2B 00, OS Windows server 2008 R2. 64 bit 8 GB ram.
>
>
> --
> You were sent this email because you opted to receive email notifications when someone created a new thread.
>
> To unsubscribe[collapse] from:
> - ...only this thread, disable notifications at https://community.progress.com/community_groups/openedge_rdbms/f/18/t/18779.aspx.
> - ...all email notifications from Progress Community, navigate to "Settings", click on the "Email" tab, then under the "Email Configuration" section, set Send Notifications to "No".
>

data:

a few days ago, i backed up a 35 GB database in 6 minutes.

another one on a customer box was 120 GB in 44 minutes.

another one was 45 GB in 15 min.[/collapse][/collapse]

Posted by Rob Fitzpatrick on 23-Jun-2015 13:24

How long does the backup take and how large are the DB and the BI?  What can you tell us about the storage subsystem?

Posted by bremmeyr on 23-Jun-2015 13:45

Thanks so much for the feedback.  

I have begun a to do list. 08 patch is on the list and truncate BI.

11 gig backup file takes 54 minutes.

From local disk to local disk is all I know. I will see what I can learn from the network and hardware admin.

Thanks for asking about the BI file. BI is 532 MB.

Posted by George Potemkin on 23-Jun-2015 13:50

Check how long it will take to backup db to the "nul" (or /dev/null on Unix). If it will take almost the same time as a backup to the disk then a bottleneck is a reading of db blocks from disks rather than a writing to a backup file on disk.

> 11 gig backup file takes 54 minutes.

I bet it's exactly the issue mentioned by TheMadDBA: writing to an existent backup file on Windows can be 10-20 times (sic!) slower than writing to a new file.

Posted by Rob Fitzpatrick on 23-Jun-2015 14:05

For comparison, I'm working with a customer whose nightly online backup (39 GB DB, 1.3 GB BI, 35 GB backup file) takes 12 minutes.  And the box has other application workload at the time, including another backup.

RHEL 5.6

4 10K SAS disks in RAID 10, ext3

OE 10.2B07 64-bit

Posted by bremmeyr on 23-Jun-2015 16:43

Great idea George.

Backup to \nul takes longer. 1 hour 4 minutes.

Something is not right.

Posted by Paul Koufalis on 23-Jun-2015 17:13

Did you backup to \nul or NUL? The former is a file in the root directory. The latter is the Windows equivalent of /dev/null.

Posted by TheMadDBA on 23-Jun-2015 17:33

I was a little surprised when I tried \nul but it works the same as NUL. At least on Windows 7. No output file was created and it "copied" a 200MB file instantly.

Bremmeyr: If you are running this during working hours and not when you normally run the backup it could cause it to slow down a bit. But writing the output to NUL means at the very least you have some IO issues to deal with on the read side (probably the write side as well).

Your Windows admin staff "should" be able to help you look at the performance data while the probkup is running and/or just in general. Also posting the details of the disk setup should give us some ideas on what the issue is.

Posted by Paul Koufalis on 23-Jun-2015 18:04

Really? Learn something new every day!

Posted by gus on 23-Jun-2015 19:29

> On Jun 23, 2015, at 2:45 PM, bremmeyr wrote:
>
> 11 gig backup file takes 54 minutes.

this is quite slow (0.2 gigabytes per minute). there is definitely something wrong. a reasonably modern single disk should be able to do writes at 50 megabytes per sec (2.5 gigabytes per minute) or higher.

-gus

Posted by CMI on 23-Jun-2015 21:01

I had a similar problem years ago when backups where taking a very long time. No errors where being reported by the HP SmartStart monitoring software and everything looked like it was operating correctly. However it turned out that one of the hot swappable disks in the disk array was not physically sitting correctly.

This thread is closed