Subject | Re[2]: [firebird-support] Restore error during unique index creation |
---|---|
Author | Dmitry Kuzmenko |
Post date | 2013-10-15T11:46:33Z |
Hello, Thomas!
Sunday, October 13, 2013, 11:32:13 AM, you wrote:
TS> With a scale 1 TPC-H backup database, I can reduce restore time from
TS> 7min 58sec to 5min 57sec by using 16384 buffers instead of 1024. Firing
TS> Perhaps you become CPU bound in your tests more quicker than I did.
well, seems you are right.
TS> If you have a look on a thread in firebird-devel started on Sept. 10,
TS> 2012, where I was mentioning InterBase XE3 got improved by parallel
TS> index creation at restore. Sounds like a good move in InterBase XE3,
TS> although I haven't tried that enhancement.
hmm, I tried that feature, and found that it can increase performance
only when disk subsystem have huge IO capabilities, like SSD.
Testing that at least not on good RAID 10 will be total waste of time.
In my case, disk was the stopper, for any number of "assistant threads", from 1
to 6 (cores I have).
Maybe improvement can be seen on disks with 600-1000 IOPS and more.
Strange, but Embarcadero must give positive examples about this
feature, but it's not. Instead we have only this:
"This helps the restore response time where there are idle threads/cores
that facilitate the engine doing the job that much quicker by benefiting
from sharing the cache for table data."
--
Dmitry Kuzmenko, www.ib-aid.com
Sunday, October 13, 2013, 11:32:13 AM, you wrote:
TS> With a scale 1 TPC-H backup database, I can reduce restore time from
TS> 7min 58sec to 5min 57sec by using 16384 buffers instead of 1024. Firing
TS> Perhaps you become CPU bound in your tests more quicker than I did.
well, seems you are right.
TS> If you have a look on a thread in firebird-devel started on Sept. 10,
TS> 2012, where I was mentioning InterBase XE3 got improved by parallel
TS> index creation at restore. Sounds like a good move in InterBase XE3,
TS> although I haven't tried that enhancement.
hmm, I tried that feature, and found that it can increase performance
only when disk subsystem have huge IO capabilities, like SSD.
Testing that at least not on good RAID 10 will be total waste of time.
In my case, disk was the stopper, for any number of "assistant threads", from 1
to 6 (cores I have).
Maybe improvement can be seen on disks with 600-1000 IOPS and more.
Strange, but Embarcadero must give positive examples about this
feature, but it's not. Instead we have only this:
"This helps the restore response time where there are idle threads/cores
that facilitate the engine doing the job that much quicker by benefiting
from sharing the cache for table data."
--
Dmitry Kuzmenko, www.ib-aid.com