You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Larry Cable <la...@yahoo.com> on 2005/01/14 00:53:17 UTC
RESEND: possible resource leak in either Derby DRDA or IBM DB2 Universal JDBC Driver
<I'm re-posting; as I did'nt see it make it to the lists>
I recently completed some benchmarking exercises (comparing O.R mapping
technologies) using Derby 10.0.2.1 and the IBM DB2 Universal JDBC
driver (v10?).
The micro benchmark was primarily intended to compare the costs of
various O.R mapping technologies such as Hiberate and JDO vs a
baseline JDBC implementation. So the focus was not DB performance
(but OR mapping performance), *however* the tests did show an alarming
and inexplicable performance issue with Derby and the DB2 JDBC driver.
The benchmarks were run on an Athlon XP 2400+ system running Fedora
core 1 and JDK 1.4.2_04, using the x86 architecture TSC to obtain
clock speed granularity timings.
When the benchmark was run against Derby in embedded mode, it displayed
(as expected) an approximately constant time for each benchmark
operation (approximately 0.85 millisecs per select/update).
I then ran the ubenchmark with the DB2 JDBC driver in the following
client/server configurations; in the same JVM as the client, in
a different JVM on the same machine, and on a different machine.
In each case the ubenchmark displayed a near linear increase in cost
(time) per iteration; the minimum being 7.15 mills and the max being
22.96 millis (that's 0.3162ms per run, or 3.1usecs per operation)
The ubenchmark is approximately as follows:
open db connection;
create table pojo (id int not null primary key, int0 int);
for (50x) {
insert pojo values (0, 0);
for (1000x) {
select * from pojo where id = 0 for update;
update pojo set int0=int0+1 where id=0;
}
delete pojo where id=0;
}
close db connection;
I also ran the same configurations using C-JDBC (using Derby embedded
in a C-JDBC controller) and saw no such linear growth in access time
with an average (constant) time of 8.33ms (min: 7.86, max 10.16)
Although I cannot (yet) identify where the problem is, I believe there
must be some problem in either the DB2 client or the derby server DRDA
implementation ...
anyone got any ideas/comments?
- Larry Cable
__________________________________
Do you Yahoo!?
Meet the all-new My Yahoo! - Try it today!
http://my.yahoo.com
Re: RESEND: possible resource leak in either Derby DRDA or IBM DB2
Universal JDBC Driver
Posted by Kathey Marsden <km...@Sourcery.Org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Larry Cable wrote:
[snip]
>
> Although I cannot (yet) identify where the problem is, I believe there
> must be some problem in either the DB2 client or the derby server DRDA
> implementation ...
>
> anyone got any ideas/comments?
>
> - Larry Cable
One potential problem is that with JCC and Network Server, prepared
statements will not get cleaned up unless they are explicitly closed.
A good check to see if this is the problem is to run
NetworkServerControl runtimeinfo and it will show how many prepared
statements are open from the server's perspective.
Kathey
>
>
>
>
>
>
> __________________________________
> Do you Yahoo!?
> Meet the all-new My Yahoo! - Try it today!
> http://my.yahoo.com
>
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFB5w4xG0h36bFmkocRAnPGAKCs3Au1mjEuCF4dEMwu1HX2KxduygCfY1G/
tTsPPCndMgnYPQwJ+jB0S0g=
=3sQ2
-----END PGP SIGNATURE-----
Re: RESEND: possible resource leak in either Derby DRDA or IBM DB2
Universal JDBC Driver
Posted by Kathey Marsden <km...@Sourcery.Org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Larry Cable wrote:
[snip]
>
> Although I cannot (yet) identify where the problem is, I believe there
> must be some problem in either the DB2 client or the derby server DRDA
> implementation ...
>
> anyone got any ideas/comments?
>
> - Larry Cable
One potential problem is that with JCC and Network Server, prepared
statements will not get cleaned up unless they are explicitly closed.
A good check to see if this is the problem is to run
NetworkServerControl runtimeinfo and it will show how many prepared
statements are open from the server's perspective.
Kathey
>
>
>
>
>
>
> __________________________________
> Do you Yahoo!?
> Meet the all-new My Yahoo! - Try it today!
> http://my.yahoo.com
>
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFB5w4xG0h36bFmkocRAnPGAKCs3Au1mjEuCF4dEMwu1HX2KxduygCfY1G/
tTsPPCndMgnYPQwJ+jB0S0g=
=3sQ2
-----END PGP SIGNATURE-----