-
-
Notifications
You must be signed in to change notification settings - Fork 213
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create a new param in GBAK to backup / restore tables/indexes in parallel (using all CPUs in CpuAffinity) [CORE1365] #1783
Comments
Commented by: Sean Leyne (seanleyne) Given that a restore is very disk intensive, I believe the bottleneck for the restore is not the CPU/processor but the disk subsystem. Therefore, I don't see any benefit in trying to perform the restore from multiple threads. Finally, you should investigate the new NBackup utility (new in v2.0) it performs backups/restores at the physical database level and runs at hardware speeds! |
Commented by: Eduardo Jedliczka (edujed) in this case, the bottleneck is not disk... It is a RAID 0+1 with SAS disks 15k RPM with 2 GB of cache. But one CPU uses 100% in all time of restore process. Of coarse, I know nbackup, but in case of corruption (hardware fail, energy loss) nbackup do not recovery the database. |
Commented by: @AlexPeshkoff There are some problems with your suggestion. Anyway I like the suggestion - restore is really CPU intensive thing (for example, indices creation is also performed at the end of restore). Not sure all of your 8 CPU's will work efficiently, but certainly it may be done faster then now. |
Commented by: Eduardo Jedliczka (edujed) Thanks for the answer. Yes, you're wright, I user FireBird Classic Server. |
Modified by: @pcisarWorkflow: jira [ 12611 ] => Firebird [ 14213 ] |
Submitted by: Eduardo Jedliczka (edujed)
Is duplicated by CORE3958
Relate to CORE2992
Votes: 1
I have a 8-core machine, and when I do a Gbak of a mid-size database (more than 15 GB) the restore time is near 2 hours using only one CPU, because the restoration process is linear.
If is possible, backuping / restoring data from 1 table per CPU concurrently (in other words, in parallel) this time will be strongly lower.
if is possible, rebuild 1 index per CPU can optimise this restore operation.
The text was updated successfully, but these errors were encountered: