Yan Zhu wrote:
> this is my test program:
>
> what I found out is, if I turne the buffered log on for the database, it leaks out
> 30 Megs when it is done, but if I turn off the logging for the informix db, it only
> leaks out a few megs, which I can't be sure either since I have other programs on
> the machine.
So the logging mode of the database makes a difference to the rate at which
DBD::Informix leaks? That's an interesting piece of
information. What are the schemas of the two tables? Is the use of the two
statements critical, or does one achieve the leak (albeit at
a slower rate)? And it is the Perl that is leaking memory, not the database server
itself?
> What I have in production is much more complicated and leaks out a lot more in
> a lot shorter time.
Not altogether unexpected. No ideas yet. It will take actual trial work to see what
is up.
I note that the test harness code takes a reference to a function, so all the
top-level code should be wrapped into a function so that
you can pass that as a reference to the memory leak tester.
> #!/usr/bin/perl
>
> use DBI;
>
> &connectpdqdb();
> &preparepdqsql();
>
> for ($i=1;$i<=100000;$i++) {
> print ("doing $i\n");
> &addvehicle();
> &adddriver();
> }
>
> &disconnectpdqdb();
>
> sub connectpdqdb {
> $dbh = DBI->connect( 'pdqtest', 'informix', 'informix', 'Informix' );
Ugh! Rewrite to use the modern (meaning since about 1997) syntax:
$dbh =
DBI->connect('dbi:Informix:pdqtest','informix','informix',{AutoCommit=>0,RaiseError=>1});
I believe you get AutoCommit On by default. You can set it explicitly (I chose 0
above, but that's your decision).
I don't suppose the archaic connect syntax is much to do with the problem.
One other issue: if your real user is 'informix', you should chant to yourself each
day "I shouldn't work on the system as root all the
time because it is dangerous; I should not work in the database as informix because it
is dangerous". And if the password is 'informix',
change it. I assume that the latter at least is just for the purposes of posting.
> if ( !defined $dbh ) {
> die "Cannot connect to Informix server: $DBI::errstr\n";
> }
With RaiseError set, your error test is redundant.
> }
>
> sub disconnectpdqdb {
> $sqlvehiclei->finish;
> $dbh->disconnect;
> }
Why only one finish? Either zero or two would be plausible; one is implausible.
Don't use finish except on select statements, and then
only if you are breaking the loop before the cursor tells you you've fetched all the
data.
> sub adddriver {
> $sqldriveri->execute(0,"1","2","a","a","01012001","a","a","01012001",
> "M","s","s","u","s","5","20","s","421311890");
> }
> sub addvehicle {
>
>$sqlvehiclei->execute(0,"111","2002","Yan","Zhu","test","test","A01","A02","farm","f","a","100","a","b","s","x","x","x","d","f","d");
> }
>
> sub preparepdqsql {
> $sqlvehiclei = $dbh->prepare( "INSERT INTO vehicle
>VALUES(?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?)");
> if ( !defined $sqlvehiclei ) {die "Cannot prepare sqlvehiclei statement:
>$DBI::errstr\n";}
And with RaiseError set, these error tests are redundant too.
> $sqldriveri = $dbh->prepare( "INSERT INTO driver
>VALUES(?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?)");
> if ( !defined $sqldriveri ) {die "Cannot prepare sqldriveri statement:
>$DBI::errstr\n";}
> }
So, I've got to invent two tables with 23 and 19 columns to reproduce this? This test
case is not yet self-contained; I doubt if it
minimal either, though it is better than some I've seen. I assume the leading zeroes
go into serial columns? Why are you using strings
such as "01012001" as date values? The normal trick for increasing the size of a leak
is to use a CHAR(20000) field and only supply 4
characters of data. Are any of the types critical -- if you change a column type from
DATE to DATETIME (say), does the problem alter?
--
Jonathan Leffler ([EMAIL PROTECTED], [EMAIL PROTECTED])
Guardian of DBD::Informix 1.00.PC2 -- see http://dbi.perl.org/
#include <disclaimer.h>
