Issue Details (XML | Word | Printable)

Key: CORE-2316
Type: Improvement Improvement
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Alexander Peshkov
Reporter: Andreas Kallenbach
Votes: 0
Watchers: 4
Operations

If you were logged in you would be able to see more operations.
Firebird Core

Throttling Nbackup on large databases

Created: 10/Feb/09 03:55 PM   Updated: 19/Jan/16 04:46 AM
Component/s: NBACKUP
Affects Version/s: 2.1.1
Fix Version/s: 2.5 Beta 1, 2.1.3, 2.0.6

File Attachments: 1. PNG File CPU Usage during incremental backup.png (32 kB)
2. PNG File graph_image.php.png (39 kB)
3. Text File iostat.log (180 kB)
4. Text File iostat2.log (180 kB)
5. Text File iostat3.log (180 kB)
6. PNG File Load Average.php.png (34 kB)
7. PNG File Load during incremental backup.png (29 kB)
8. PNG File Memory Usage during incremental backup.png (30 kB)
9. Text File mpstat.log (22 kB)
10. Text File Query Execution Comparison (0.9 kB)
11. Text File Top Command during nbackup (9 kB)

Environment:
Fedora release 7 (Moonshine) Redhat Tikanga 5
FirebirdSS-2.1.1.17910-0.nptl.i686.rpm
Dell Poweredge Server 1750, P4-Dual Core-Xeon 2.8GHZ, 3GB Ram, Direct Attached SCSI RAID10 14-Drive 500GB Total

QA Status: No test


 Description  « Hide
We have a 45GB database that runs on a fairly well equipped machine and run a full nbackup once a month and an incremental once a day at 3am. The incremental takes around 12 minutes to complete, but during that time our regular use of the database crawls to an almost imperceptible stop.

Can nbackup be throttled to only consume 20%-50% of the system resources? While the backup itself may take longer, the users on the database could still continue to use the database. As it is, anyone using the database during an incremental backup will just take a break for 10 minutes because the backup is so intensive.

Are there other solutions to making nbackup more efficient and allowing other users to continue working on a database this size?

I'm not interested in setting up replication for a variety of reasons, but some sort of log-shipping type method has become increasingly attractive to keep a warm-backup ready in the event that the nasty(tm) occurs. Nbackup seems to be the only close solution but it has the drawback of almost locking the use of a 45GB database file.

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
There are no subversion log entries for this issue yet.