Skip to content
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

Closed
firebird-automations opened this issue Nov 18, 2011 · 10 comments

Comments

@firebird-automations
Copy link
Collaborator

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?

@firebird-automations
Copy link
Collaborator Author

Commented by: @hvlad

I see no bug there. Engine just do what you ask it to do.

@firebird-automations
Copy link
Collaborator Author

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).

@firebird-automations
Copy link
Collaborator Author

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..
and about your worry abut disc and CPU consumption i know that but client can accept this slowdown for 10 minutes but never accept then he/she must buy another machine only for restore process

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)
will be good to see e.g. -buffers_at_restore - or something similar

@firebird-automations
Copy link
Collaborator Author

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.

@firebird-automations
Copy link
Collaborator Author

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
and i must dig in source code of component what i use (it have not this option) or search for some updates

thanks for asnwer also at "support question"
isc_spb_res_buffers, isc_spb_prp_page_buffers is what i looking for
this ticket should be closed

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

status: Open [ 1 ] => Resolved [ 5 ]

resolution: Won't Fix [ 2 ]

@firebird-automations
Copy link
Collaborator Author

Commented by: @livius2

i dig source code an i see that
my previous message is wrong
you say in "GFIX" service - i misss this

this should be possible at "GBAK" service as one running statement

@firebird-automations
Copy link
Collaborator Author

Commented by: @dyemanov

What's wrong with calling two services sequently?

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

status: Resolved [ 5 ] => Closed [ 6 ]

@firebird-automations
Copy link
Collaborator Author

Commented by: @livius2

that you must manage two services for doing restore process not one

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant