gbak -b -g db.fdb db.fbk
When gbak is not "attached" to cores (uses all), or "attached" to another processor core where the Firebird SuperServer runs (for example, fbserver. exe at core 0, and gbak.exe at core 1), gbak nearly not loading used core, and fbserver.exe loads it's core only at 50%.
When we attach gbak.exe to the same core that uses fbserver.exe, backup speed raises nearly 2 times, and fbserver.exe loads core at 95%. Example results for gbak -b -g of 3.8 gb database:
- fbserver and gbak on the same core - 9 min 22 sec.
- fbserver and gbak on different cores - 15 min 41 sec.
So, right now we do not suggest to use local protocol for Firebird 1.5, and use localhost instead. More tests on the way, stay tuned.
2 comments:
Maybe you can explain why using the service manager is so much faster than using either local protocol or localhost connections, too?
And additionally, with a high bandwidth connection, backing up a database from the server to the local client *should* be faster because the I/O throughput is distributed to two different harddisks, but that's not at all the case.
this is not a question (about Services API), because in this case server does work by itself, without any overhead of "conversating" with gbak.
So, the Services API is the fastest way to do backup (on one computer).
We made backup test long time ago, and now re-made some parts of it. The article is on the way.
But, idea of server and client connected by 1gbit network is interesting to test backup, maybe we will check this, thanks.
BTW - current test of course was made using different HDDs for DB and backup. But, the better disks are, the less difference with the backup on the same disk where DB is.
Post a Comment