On any version of Interbase (2009 -> XE3) when running gbak (-b or -d) memory usage grows up to 100 % during the process.
With -d even if few pages has been modified (14 of 1250000) it seems all data are loaded in memory

When gbak stop as long as there are users connected, memory is not released, so it remains at 100% and all further process fails to start

We tried to change some parameters in IBconfig files but with no success

On some DB >30 gb all the system is often freezed  after such gbak; no more connections allowed and we have to restart Interbase process

Is there any command line option with gbak ibserver or other utility to avoid this situation, to force memory to be released or not growing up to 100% ?

Thanks
Yves

Very nice to you, this is exactly what we were looking for

Very good tool 
It will help us to resolve many problems

Thanks a lot

> {quote:title=Michael Danninger wrote:}{quote}
> We use this tool:
> http://www.uwe-sieber.de/ntcacheset_e.html
> to limit the system file cache size.
> This works for us with ib 2009.
> 
> Am 10.12.14 17:48, schrieb Yves Ganier:
> > I have downloaded Hotfix 2 for XE3 and my test shows this problem is corrected, thanks but what can we do for our customers with IB 2009 installed ?
> > We have already installed Update 4 for IB2009 and I didn't see any new Hotfix .
> > Direct I/O slows too much all the access on the database
> >
> >> {quote:title=quinn wildman wrote:}{quote}
> >> I imagine what you are seeing is the system file cache which generally
> >> works this way on large files. There are two options here:
> >>
> >> 1. InterBase XE or InterBase XE before update 4, hotfix 2 - turn direct
> >> i/o on.
> >> 2. Use XE3 Update 4, hotfix 2, or XE7.
> >>
> >>
> >> Yves Ganier wrote:
> >>> On any version of Interbase (2009 -> XE3) when running gbak (-b or -d) memory usage grows up to 100 % during the process.
> >>> With -d even if few pages has been modified (14 of 1250000) it seems all data are loaded in memory
> >>>
> >>> When gbak stop as long as there are users connected, memory is not released, so it remains at 100% and all further process fails to start
> >>>
> >>> We tried to change some parameters in IBconfig files but with no success
> >>>
> >>> On some DB >30 gb all the system is often freezed  after such gbak; no more connections allowed and we have to restart Interbase process
> >>>
> >>> Is there any command line option with gbak ibserver or other utility to avoid this situation, to force memory to be released or not growing up to 100% ?
> >>>
> >>> Thanks
> >>> Yves
> >>>

We use this tool:
http://www.uwe-sieber.de/ntcacheset_e.html
to limit the system file cache size.
This works for us with ib 2009.

Am 10.12.14 17:48, schrieb Yves Ganier:
> I have downloaded Hotfix 2 for XE3 and my test shows this problem is corrected, thanks but what can we do for our customers with IB 2009 installed ?
> We have already installed Update 4 for IB2009 and I didn't see any new Hotfix .
> Direct I/O slows too much all the access on the database
>
>> {quote:title=quinn wildman wrote:}{quote}
>> I imagine what you are seeing is the system file cache which generally
>> works this way on large files. There are two options here:
>>
>> 1. InterBase XE or InterBase XE before update 4, hotfix 2 - turn direct
>> i/o on.
>> 2. Use XE3 Update 4, hotfix 2, or XE7.
>>
>>
>> Yves Ganier wrote:
>>> On any version of Interbase (2009 -> XE3) when running gbak (-b or -d) memory usage grows up to 100 % during the process.
>>> With -d even if few pages has been modified (14 of 1250000) it seems all data are loaded in memory
>>>
>>> When gbak stop as long as there are users connected, memory is not released, so it remains at 100% and all further process fails to start
>>>
>>> We tried to change some parameters in IBconfig files but with no success
>>>
>>> On some DB >30 gb all the system is often freezed  after such gbak; no more connections allowed and we have to restart Interbase process
>>>
>>> Is there any command line option with gbak ibserver or other utility to avoid this situation, to force memory to be released or not growing up to 100% ?
>>>
>>> Thanks
>>> Yves
>>>

OK thanks 
We are looking into windows system tools to see how to limit memory usage for specific process or program

> {quote:title=quinn wildman wrote:}{quote}
> Sorry, the only option is to update.
> 
> Yves Ganier wrote:
> > I have downloaded Hotfix 2 for XE3 and my test shows this problem is corrected, thanks but what can we do for our customers with IB 2009 installed ?

Sorry, the only option is to update.

Yves Ganier wrote:
> I have downloaded Hotfix 2 for XE3 and my test shows this problem is corrected, thanks but what can we do for our customers with IB 2009 installed ?

I have downloaded Hotfix 2 for XE3 and my test shows this problem is corrected, thanks but what can we do for our customers with IB 2009 installed ?
We have already installed Update 4 for IB2009 and I didn't see any new Hotfix .
Direct I/O slows too much all the access on the database

> {quote:title=quinn wildman wrote:}{quote}
> I imagine what you are seeing is the system file cache which generally 
> works this way on large files. There are two options here:
> 
> 1. InterBase XE or InterBase XE before update 4, hotfix 2 - turn direct 
> i/o on.
> 2. Use XE3 Update 4, hotfix 2, or XE7.
> 
> 
> Yves Ganier wrote:
> > On any version of Interbase (2009 -> XE3) when running gbak (-b or -d) memory usage grows up to 100 % during the process.
> > With -d even if few pages has been modified (14 of 1250000) it seems all data are loaded in memory
> >
> > When gbak stop as long as there are users connected, memory is not released, so it remains at 100% and all further process fails to start
> >
> > We tried to change some parameters in IBconfig files but with no success
> >
> > On some DB >30 gb all the system is often freezed  after such gbak; no more connections allowed and we have to restart Interbase process
> >
> > Is there any command line option with gbak ibserver or other utility to avoid this situation, to force memory to be released or not growing up to 100% ?
> >
> > Thanks
> > Yves
> >

I imagine what you are seeing is the system file cache which generally 
works this way on large files. There are two options here:

1. InterBase XE or InterBase XE before update 4, hotfix 2 - turn direct 
i/o on.
2. Use XE3 Update 4, hotfix 2, or XE7.


Yves Ganier wrote:
> On any version of Interbase (2009 -> XE3) when running gbak (-b or -d) memory usage grows up to 100 % during the process.
> With -d even if few pages has been modified (14 of 1250000) it seems all data are loaded in memory
>
> When gbak stop as long as there are users connected, memory is not released, so it remains at 100% and all further process fails to start
>
> We tried to change some parameters in IBconfig files but with no success
>
> On some DB >30 gb all the system is often freezed  after such gbak; no more connections allowed and we have to restart Interbase process
>
> Is there any command line option with gbak ibserver or other utility to avoid this situation, to force memory to be released or not growing up to 100% ?
>
> Thanks
> Yves
>