I should also have added "or maybe the test is not tickling the bug".
Can you update the test code I sent so that the types of the column match
the types in your tables? Does it leak then?
Have you allocated enough swap space? You say that you are running out of
memory, but how do you know that? What are the symptoms of being out of
memory? Is it actually driven by a bug in the o/s (or, more likely, a bug
in the database server)?
You need to be precise about stating your problem -- I cannot help you if
the information you give is vague; I can only give you equally vague
answers pointing out possibilities. It would not take you long to wrap up
your code that reproduces the problem into a function (or set of functions)
like the stuff I sent. You just have to make the code free-standing so
that it creates its own tables as needed. I like temp tables because they
vanish automatically; if you can demonstrate that the problem only occurs
with regular (non-temp) tables, I'll take example code which uses regular
tables. But without knowing exactly what is happening and how you can tell
that you've run out of memory and why you think it is
Perl+DBI+DBD::Informix that is causing the problem rather than something
else, it is very difficult to help you. Meaning, essentially impossible;
the best I can do is prod you with suggestions and questions until you give
me the data I need.
--
Jonathan Leffler ([EMAIL PROTECTED])
STSM, Informix Database Engineering, IBM Data Management Solutions
4100 Bohannon Drive, Menlo Park, CA 94025
Tel: +1 650-926-6921 Tie-Line: 630-6921
"I don't suffer from insanity; I enjoy every minute of it!"
Jonathan Leffler
To: Yan Zhu
<[EMAIL PROTECTED]>
04/02/02 04:29 PM cc: DBI Users Mailing List
<[EMAIL PROTECTED]>
From: Jonathan Leffler/Menlo
Park/IBM@IBMUS
Subject: Re: memory leak in
DBD::Informix(Document link: Jonathan Leffler)
Yan Zhu,
If your Perl process is not growing (and the SZ column *is* the one to
monitor; it looks good but you need more data points than you show), then
there isn't a leak in Perl + DBI + DBD::Informix. You may have to track
down what the database server is doing. How much memory is in your
machine? What's the config space set to? What else is running on it?
Where has all the memory gone? Maybe you need to do a (reverse numeric)
sort on the SZ column of the output.
--
Jonathan Leffler ([EMAIL PROTECTED])
STSM, Informix Database Engineering, IBM Data Management Solutions
4100 Bohannon Drive, Menlo Park, CA 94025
Tel: +1 650-926-6921 Tie-Line: 630-6921
"I don't suffer from insanity; I enjoy every minute of it!"
Yan Zhu
<yan.zhu@infinity-ins To: Jonathan Leffler/Menlo
Park/IBM@IBMUS
urance.com> cc: DBI Users Mailing List
<[EMAIL PROTECTED]>
Subject: Re: memory leak in
DBD::Informix
04/02/02 11:39 AM
here is my result, the SZ ( I assume that is the size we should be looking
at)
did stablize at 827. However, I have no more memory left on my box at this
point,
they all leaked out. So I am going to wait till tonight and reboot the
machine and try
again.
yan
# DBI->connect('dbi:Informix:pdqtest', 'informix', '');
# Connect Attribute: RaiseError => 1
# F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME
CMD
# 8 O 0 24408 24310 0 57 20 ? 662 pts/7 0:00
test.pl
doing 100
doing 200
doing 300
doing 400
doing 500
doing 600
doing 700
doing 800
doing 900
doing 1000
doing 1100
doing 1200
doing 1300
doing 1400
doing 1500
doing 1600
doing 1700
doing 1800
# 8 O 0 24408 24310 3 59 20 ? 827 pts/7 0:02
test.pl
doing 1900
doing 2000
doing 2100
doing 2200
doing 2300
doing 2400
doing 2500
doing 2600
doing 2700
doing 2800
doing 2900
doing 3000
doing 3100
doing 3200
doing 3300
doing 3400
doing 3500
doing 3600
doing 3700
# 8 S 0 24408 24310 5 69 20 ? 827 ? pts/7 0:05
test.pl
doing 3800
doing 3900
doing 4000
doing 4100
Jonathan Leffler wrote:
> Previously sent to Yan Zhu directly - bounced by onion.perl.org.
> Attempting a resend from my subscribed email address...
>
> Dear Yan Zhu,
>
> The attachment is the test case I created derived from the information
> you sent. I tested it on Solaris 7 with Perl 5.7.3, DBI 1.21,
> DBD::Informix 1.00.PC2, ESQL/C 9.51.UC1, IDS 9.30.UC1 (gcc 3.0.4).
>
> I tested it against unlogged, (buffered) logged and MODE ANSI databases,
> with no difference in the memory behaviour (Perl stabilized at size 756
> according to 'ps'). The one main difference I noted was that the MODE
> ANSI code ran about 1/3 the rate of the other code; this is primarily
> due to the dact that AutoCommit was on so there are three times as many
> database operations (an explicit BEGIN WORK, the operation, an explicit
> COMMIT WORK) as in the other database types.
>
> Can you return this to me modified so that it demonstrates the leak, and
> include the 'perl -V' output. I've included mine below. As a
> performance indicator, I was getting around 1200 operations per 'ps'
> output with the non-ANSI database and 300-400 operations per 'ps' output
> with the MODE ANSI database. The connection mode was oltlitcp to my
> local machine in each case.
>
> --
> Jonathan Leffler #include <disclaimer.h>
> STSM, Informix Database Engineering, IBM Data Management Solutions
> Phone: +1 650-926-6921 Tie-line: 630-6921
> Email: [EMAIL PROTECTED] (RIP [EMAIL PROTECTED])
> Notes ID: Jonathan Leffler/Menlo Park/IBM@IBMUS
> Guardian of DBD::Informix v1.00.PC2 -- http://dbi.perl.org
> *=*=*=*=*=* THE END IS NIGH! *=*=*=*=*=*
> Please use [EMAIL PROTECTED] because [EMAIL PROTECTED] will
> not work from 2002-07-01. Expect slower responses from 2002-02-18
> because email will be sent to Notes and I can't use Lotus Notes as
> fast as Unix email. One day, this signature will shrink!
>
> Summary of my perl5 (revision 5.0 version 7 subversion 3) configuration:
> Platform:
> osname=solaris, osvers=2.7, archname=sun4-solaris
> uname='sunos anubis 5.7 generic_106541-18 sun4u sparc '
> config_args='-Dusedevel'
> hint=previous, useposix=true, d_sigaction=define
> usethreads=undef use5005threads=undef useithreads=undef
usemultiplicity=undef
> useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
> use64bitint=undef use64bitall=undef uselongdouble=undef
> usemymalloc=n, bincompat5005=undef
> Compiler:
> cc='gcc', ccflags ='-fno-strict-aliasing -I/usr/gnu/include
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
> optimize='-O',
> cppflags='-fno-strict-aliasing -I/usr/gnu/include
-fno-strict-aliasing -I/usr/gnu/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64'
> ccversion='', gccversion='3.0.4', gccosandvers='solaris2.7'
> intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321
> d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
> ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=8
> alignbytes=8, prototype=define
> Linker and Libraries:
> ld='gcc', ldflags =' -L/usr/gnu/lib '
> libpth=/usr/gnu/lib /usr/lib /usr/ccs/lib
> libs=-lsocket -lnsl -lgdbm -ldb -ldl -lm -lc
> perllibs=-lsocket -lnsl -ldl -lm -lc
> libc=/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a
> Dynamic Linking:
> dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' '
> cccdlflags='-fPIC', lddlflags='-G -L/usr/gnu/lib'
>
> Characteristics of this binary (from libperl):
> Compile-time options: USE_LARGE_FILES
> Built under solaris
> Compiled at Mar 6 2002 10:38:16
> @INC:
> /usr/perl/v5.7.3/lib/5.7.3/sun4-solaris
> /usr/perl/v5.7.3/lib/5.7.3
> /usr/perl/v5.7.3/lib/site_perl/5.7.3/sun4-solaris
> /usr/perl/v5.7.3/lib/site_perl/5.7.3
> /usr/perl/v5.7.3/lib/site_perl
> .
>
>
------------------------------------------------------------------------
> Name: yanzhu.pl
> yanzhu.pl Type: Plain Text (TEXT/PLAIN)
> Encoding: BASE64
