Subject | RE: [firebird-support] Re: Getting IBServer to release memory |
---|---|
Author | Alan McDonald |
Post date | 2003-07-10T13:50:34Z |
in my experience, the server will release memory as it is not required. It
may take some time or some further continued use at a "more normal" level to
do so, but I have seen it release memory without doing anything special to
it.
I still want to make it clear, though, that updating a lot of records once a
month is not the issue, it is updating these records without a rational
commit strategy.
e.g.
UPDATE TABLEA SET FIELD1=VALUE;
is a single mass update to perhaps millions of records.
On the other hand, a client-side loop where this statment is issued to
subsets of records in TABLEA and where, after each subset, you commit the
update before proceeding to the next subset update, is far better practice.
Another way is to use one client transaction and SPs with nested FOR loops.
Here you may not need to commit until the last loop exit (i.e. back at the
client) but it is still far more efficient than the first method above. If
your data is relational in terms of parent child hierarchy, then this lends
itself perfectly to nested loops. I can swear that this nested loop method
improves speed and efficiency quite dramatically.
I can't comment on the difference here with linux but I would hazard to
guess that the server mechanics are similar enough across the platforms that
there would be little real difference.
Alan
may take some time or some further continued use at a "more normal" level to
do so, but I have seen it release memory without doing anything special to
it.
I still want to make it clear, though, that updating a lot of records once a
month is not the issue, it is updating these records without a rational
commit strategy.
e.g.
UPDATE TABLEA SET FIELD1=VALUE;
is a single mass update to perhaps millions of records.
On the other hand, a client-side loop where this statment is issued to
subsets of records in TABLEA and where, after each subset, you commit the
update before proceeding to the next subset update, is far better practice.
Another way is to use one client transaction and SPs with nested FOR loops.
Here you may not need to commit until the last loop exit (i.e. back at the
client) but it is still far more efficient than the first method above. If
your data is relational in terms of parent child hierarchy, then this lends
itself perfectly to nested loops. I can swear that this nested loop method
improves speed and efficiency quite dramatically.
I can't comment on the difference here with linux but I would hazard to
guess that the server mechanics are similar enough across the platforms that
there would be little real difference.
Alan
> -----Original Message-----
> From: chriskudla [mailto:chris@...]
> Sent: Thursday, 10 July 2003 11:27 PM
> To: firebird-support@yahoogroups.com
> Subject: [firebird-support] Re: Getting IBServer to release memory
>
>
> I know that the update of a large number of records is not ideal.
> Unfortunately we have a user who likes to update once a month and so
> this situation arises.
> What I really want to know is if the behaviour of ibserver in terms
> of not releasing memory is 'normal' and whether anything can be done
> to release the memory back to the OS, other than stopping and
> restarting the service. Is this perhaps a Windows issue and might be
> solved by moving the database onto a Linux server?
>
> Thanks for the responses so far
>
> Chris
>
>
> --- In firebird-support@yahoogroups.com, Alan McDonald <alan@m...>
> wrote:
> > Svein has answered this - I might add that by doing small amounts of
> > updates/inserts and then committing also keeps memory usage to very
> > managable levels. It also keeps transactions moving along nicely and
> > genrally keeps the server feeling "light". Doing 1 million record
> updates
> > and then committing makes the server feel very heavy. The commit
> may well
> > take much longer than the update.
> >
> > Alan
> >
> > > -----Original Message-----
> > > From: chriskudla [mailto:chris@o...]
> > > Sent: Thursday, 10 July 2003 6:30 PM
> > > To: firebird-support@yahoogroups.com
> > > Subject: [firebird-support] Re: Getting IBServer to release memory
> > >
> > >
> > > We update all the records and then do a commit. I am not sure what
> > > you mean by 'incremental commit', could you explain?
> > > Thanks in advance :-)
> > >
> > >
> > > --- In firebird-support@yahoogroups.com, "Alan McDonald"
> <alan@m...>
> > > wrote:
> > > > does your fairly large volume update use incremental commit? or
> > > does it
> > > > update thousands of records before committing?
> > > > Alan
> > > >
> > > > > -----Original Message-----
> > > > > From: chriskudla [mailto:chris@o...]
> > > > > Sent: Wednesday, 9 July 2003 11:40 PM
> > > > > To: firebird-support@yahoogroups.com
> > > > > Subject: [firebird-support] Getting IBServer to release memory
> > > > >
> > > > >
> > > > > One of our users running Firebird 1.0 Classic on Windows 2003
> > > Server
> > > > > has occasions where they perform a procedure which seems to
> cause
> > > > > IBserver to use large quantities of memory. We have checked
> the
> > > > > application using Memproof and there are no open transactions
> or
> > > > > memory leaks.
> > > > > Our app is written using Delphi 7 and we are using the TIBSQL
> > > > > component to update fairly large volumes of transactions in
> this
> > > > > particular function.
> > > > > It seems as if IBserver re-uses the memory (which we are
> > > monitoring
> > > > > with Task Manager) however it seems the only way to make it
> > > release
> > > > > the memory is to stop and restart the service.
> > > > > This is a bit problematic as the server is in use for at
> least 12
> > > > > hours of the day and is complicated by the fact the they are
> using
> > > > > Terminal Services for the client connections to the server,
> > > meaning
> > > > > that the client applications plus the IBserver are all
> running on
> > > the
> > > > > one machine.
> > > > > Is the only solution to stop and start the Ibserver on a
> regular
> > > > > basis?
> > > > >
> > > > > I have also read that one can call SetProcessWorkingSetSize
> and
> > > pass
> > > > > it the handle of the process you want to have swept and -1, -
> 1 as
> > > the
> > > > > other two params. This causes windows to sweep the app to
> release
> > > > > heap space. I only seem to be able to run this function on a
> > > process
> > > > > if it running as an application. When I try to run it against
> > > > > IBServer running as a service, I get "Access Denied" errors.
> > > > > Is it worthwhile running Interbase as an app, rather than as a
> > > > > service, and then running this function occasionally
> throughout
> > > the
> > > > > day, or will this just be detrimental to the performance of
> the
> > > > > server, as now its memory is all sitting as virtual memory on
> the
> > > > > hard disk?
> > > > > The reason why I am doing this is to make any extra memory
> > > available
> > > > > for the EXE's that are also running on the server.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > To unsubscribe from this group, send an email to:
> > > > > firebird-support-unsubscribe@yahoogroups.com
> > > > >
> > > > >
> > > > >
> > > > > Your use of Yahoo! Groups is subject to
> > > http://docs.yahoo.com/info/terms/
> > > > >
> > > > >
> > >
> > >
> > >
> > > To unsubscribe from this group, send an email to:
> > > firebird-support-unsubscribe@yahoogroups.com
> > >
> > >
> > >
> > > Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
> > >
> > >
>
>
>
> To unsubscribe from this group, send an email to:
> firebird-support-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>