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
Restore process consume memory as DefaultDbCachePages what is not acceptable [CORE3667] #4017
Comments
Commented by: @hvlad I see no bug there. Engine just do what you ask it to do. |
Commented by: @dyemanov Sorry, but this is nonsense. Restore with a small cache is likely to be unacceptedly slow. But if you insist, then it can be easily achived with the -buffers switch for GBAK during restore. Regardless, if you do need to restore immediately while your original database is still being accessed by users, it's much better to do that on a separate host. It's not only about memory consuption but also about CPU and disk usage that would make your original database to perform badly while the restore process is running. I tend to reject this request in both incarnations (improvement or bug). |
Commented by: @livius2 >>Restore with a small cache is likely to be unacceptedly slow. slower is swap to disk when FB server consume all memory.. but "-buffers" is ok. but after restore process we must then set buffers again to some value (i do not know what is "default" when server see it then use value not from database only from config) and with command line this is ok but by service this is not possible by one service (or i missing something) |
Commented by: @dyemanov > slower is swap to disk when FB server consume all memory Only in your case. Almost everybody else ask us developers to speed up the restore process in the any possible way. > but after restore process we must then set buffers again to some value Setting it to zero (e.g. with GFIX) makes the config setting actual again. > but by service this is not possible Both are possible: isc_spb_res_buffers for the GBAK service and isc_spb_prp_page_buffers for the GFIX service. |
Commented by: @livius2 >>Both are possible: isc_spb_res_buffers for the GBAK service and isc_spb_prp_page_buffers for the GFIX service i see that now that feature already exists thanks for asnwer also at "support question" |
Commented by: @livius2 i dig source code an i see that this should be possible at "GBAK" service as one running statement |
Commented by: @dyemanov What's wrong with calling two services sequently? |
Modified by: @pcisarstatus: Resolved [ 5 ] => Closed [ 6 ] |
Commented by: @livius2 that you must manage two services for doing restore process not one |
Submitted by: @livius2
Situation
DefaultDbCachePages e.g. 131072
1. On serwer is database e.g 3GB test.fdb
2. we do backup process test.bak
3. we restore database test_rest.fdb
When restore proces of database start then serwer consume memory for pages as big as is DefaultDbCachePages setting for this new test_rest.fdb
this is not acceptable because server must have then free memory DefaultDbCachePages x2 (1xDefaultDbCachePages for test.fdb and 1xDefaultDbCachePages for in restore process test_rest.fdb)
server should use small amout of RAM for restore proces eg. max 4096 pages
I post this as Improvement but may be should post this as bug?
The text was updated successfully, but these errors were encountered: