Board index » delphi » HUGE MEMORY LEAK in Interbase makes product completely unusable

Alexandre Kozlo

Delphi Developer
Sat, 13 Dec 2003 22:32:51 GMT

HUGE MEMORY LEAK in Interbase makes product completely unusable

Hi Chris,

we use static statement which created only once after connection.
So, it helps and does product usable.

Alexander

Quote
Chris Smith wrote:
> Over the weekend, I had the pleasure to find the location of an enormous
> memory leak in Interbase. I searched the newsgroups, and other threads
> related to IB, and found several people complaining about such leaks.
> However, all of the responses from Borland folks have stated that the issue
> was due to unclosed connections, etc.

> Well, I have a reproducible test case that is only a couple lines.

> My configuration is as follows:

> Interbase 6.01 (Open Source)
> Interbase Client 1.60 (I have also reproduced with 2.0) (Open Source)
> JDBC Drivers 1.60
> Windows 2000

> The problem appears to show itself when using JDBC Statement operations that
> perform updates (delete, update, etc.). Here is the sample code that will
> allow you to deplete your computer of all its memory.

> try
> {
>     Connection con = /* Create JDBC connection here using
> "interbase.interclient.Driver" */
>     for( int i = 0; i < 1000; i++ )
>     {
>         int newVal = (int)(Math.random() * 100000);
>         Statement st = con.createStatement();
>         st.executeUpdate( "update foo set foocol = " + newVal + " where
> foocol > 0" );
>         st.close();
>         con.commit();
>     }
>     con.close();
> }
> catch( Exception e )
> {
>     e.printStackTrace();
> }

> The DDL is the following:    create table foo( foocol integer );

> I insert a row before testing, but it doesn't matter, the leak occurs in
> either case.

> When you run this program, watch the memory consumption of ibserver.exe and
> interserver.exe (the connection). Both of these processes will leak memory
> at a huge rate. When the program exits, none of the memory is reclaimed.

> The most interesting part is that if you change the Statement above to a
> PreparedStatement, the processes hardly leak at all. If they do leak it is
> at a very low rate.

> If there is anything I am missing, or something I am doing wrong, please let
> me know.

> --Chris.

 
Carsten Schaefe

Delphi Developer
Sun, 14 Dec 2003 21:55:07 GMT

Re:HUGE MEMORY LEAK in Interbase makes product completely unusable


Hi,
I had the same memory problems with interserver when i start to use
interbase.
I really think interclient/server has problems with closing statements.
Before using IB i never had these problems even if i don't close statements
at all.
You should avoid creating and closing statements in a loop.
In your case you can open the statement before the loop (better is working
with PreparedStatements)
and close it after the loop and you don't have to explicit commit the
statement, when you have not
set con.setAutocommit(false).

gruse
Carsten

"Chris Smith" <csm...@tripwire.com> schrieb im Newsbeitrag
news:3b37834f$1_2@dnews...

Quote
> Over the weekend, I had the pleasure to find the location of an enormous
> memory leak in Interbase. I searched the newsgroups, and other threads
> related to IB, and found several people complaining about such leaks.
> However, all of the responses from Borland folks have stated that the
issue
> was due to unclosed connections, etc.

> Well, I have a reproducible test case that is only a couple lines.

> My configuration is as follows:

> Interbase 6.01 (Open Source)
> Interbase Client 1.60 (I have also reproduced with 2.0) (Open Source)
> JDBC Drivers 1.60
> Windows 2000

> The problem appears to show itself when using JDBC Statement operations
that
> perform updates (delete, update, etc.). Here is the sample code that will
> allow you to deplete your computer of all its memory.

> try
> {
>     Connection con = /* Create JDBC connection here using
> "interbase.interclient.Driver" */
>     for( int i = 0; i < 1000; i++ )
>     {
>         int newVal = (int)(Math.random() * 100000);
>         Statement st = con.createStatement();
>         st.executeUpdate( "update foo set foocol = " + newVal + " where
> foocol > 0" );
>         st.close();
>         con.commit();
>     }
>     con.close();
> }
> catch( Exception e )
> {
>     e.printStackTrace();
> }

Jaimy Azl

Delphi Developer
Mon, 15 Dec 2003 16:12:09 GMT

Re:HUGE MEMORY LEAK in Interbase makes product completely unusable


Quote
> For Interbase, it will still happily allocate memory up to the limit you
> set. Assuming 4K page size, you should set max pages to no more than
10,000.
> This will allow IB to use up to 40 meg - but no more - for caching (more
> than 40 meg results in a performance "knee"). I cannot speak for
interserver
> as I haven't used it, but I've never seen a problem with IB eating all
> memory.

I have tried to set max page buffers up to 40960, yes... it would increase
on searching performance, but it allocates memory so much that caused
windows to drop <g>. In that case, i reduce the size to 9600 pages, but the
searching performace drop to unacceptable limit. i just have 250MB database
which consist of 1000.000 indexed keywords. is there anymore tricks on the
lower grade rather than re-tuning the scripts (stored procedures, etc) ?

Regars,

Jaimy.

Ingo Adle

Delphi Developer
Sat, 20 Dec 2003 03:49:52 GMT

Re:HUGE MEMORY LEAK in Interbase makes product completely unusable


I have the same problem.

Accessing the same db with C++ (IBX) is perfectly ok.
When I insert data with jdbc it uses all of the systems memory (= more
than physical memory = 265MB).

I have to restart the server to get the memory back.

It doesn't respond to the maximum memory settings as it does with C++.

Ingo

Quote
Chris Smith wrote:
> Over the weekend, I had the pleasure to find the location of an enormous
> memory leak in Interbase. I searched the newsgroups, and other threads
> related to IB, and found several people complaining about such leaks.
> However, all of the responses from Borland folks have stated that the issue
> was due to unclosed connections, etc.

> Well, I have a reproducible test case that is only a couple lines.

> My configuration is as follows:

> Interbase 6.01 (Open Source)
> Interbase Client 1.60 (I have also reproduced with 2.0) (Open Source)
> JDBC Drivers 1.60
> Windows 2000

> The problem appears to show itself when using JDBC Statement operations that
> perform updates (delete, update, etc.). Here is the sample code that will
> allow you to deplete your computer of all its memory.

> try
> {
>     Connection con = /* Create JDBC connection here using
> "interbase.interclient.Driver" */
>     for( int i = 0; i < 1000; i++ )
>     {
>         int newVal = (int)(Math.random() * 100000);
>         Statement st = con.createStatement();
>         st.executeUpdate( "update foo set foocol = " + newVal + " where
> foocol > 0" );
>         st.close();
>         con.commit();
>     }
>     con.close();
> }
> catch( Exception e )
> {
>     e.printStackTrace();
> }

> The DDL is the following:    create table foo( foocol integer );

> I insert a row before testing, but it doesn't matter, the leak occurs in
> either case.

> When you run this program, watch the memory consumption of ibserver.exe and
> interserver.exe (the connection). Both of these processes will leak memory
> at a huge rate. When the program exits, none of the memory is reclaimed.

> The most interesting part is that if you change the Statement above to a
> PreparedStatement, the processes hardly leak at all. If they do leak it is
> at a very low rate.

> If there is anything I am missing, or something I am doing wrong, please let
> me know.

> --Chris.

Aaron Ruddick[Borland

Delphi Developer
Fri, 16 Jan 2004 23:03:20 GMT

Re:HUGE MEMORY LEAK in Interbase makes product completely unusable


Ingo,

We are having trouble getting a reproducible case for this Memory Leak.  If you
have a small example that you could email me it would be wonderful.

The example provided by Chris (in this thread) doesn't reproduce the memory leak
on our systems.  I don't question its validity, but I need a better test case.
Any additional information you have would be wonderful.

Also, are you using IC2.X or an earlier beta?

Quote
Ingo Adler wrote:
> > try
> > {
> >     Connection con = /* Create JDBC connection here using
> > "interbase.interclient.Driver" */
> >     for( int i = 0; i < 1000; i++ )
> >     {
> >         int newVal = (int)(Math.random() * 100000);
> >         Statement st = con.createStatement();
> >         st.executeUpdate( "update foo set foocol = " + newVal + " where
> > foocol > 0" );
> >         st.close();
> >         con.commit();
> >     }
> >     con.close();
> > }
> > catch( Exception e )
> > {
> >     e.printStackTrace();
> > }

> > The DDL is the following:    create table foo( foocol integer );

> > I insert a row before testing, but it doesn't matter, the leak occurs in
> > either case.

> > When you run this program, watch the memory consumption of ibserver.exe and
> > interserver.exe (the connection). Both of these processes will leak memory
> > at a huge rate. When the program exits, none of the memory is reclaimed.

> > The most interesting part is that if you change the Statement above to a
> > PreparedStatement, the processes hardly leak at all. If they do leak it is
> > at a very low rate.

> > If there is anything I am missing, or something I am doing wrong, please let
> > me know.

> > --Chris.

--
Thank you,
Aaron Ruddick
InterBase QA
http://www.borland.com/interbase
Go to page: [1] [2]

Other Threads