[CDBI] C::DBI Memory usage

Aaron Trevena aaron.trevena at gmail.com
Mon May 29 19:59:41 BST 2006


On 26/05/06, Perrin Harkins <perrin at elem.com> wrote:
> On Fri, 2006-05-26 at 13:44 +0100, Aaron Trevena wrote:
> > Changing from connect_cached to connect has at least halved the memory
> > usage increases which is a bonus
>
> That's odd.  Ima::DBI already keeps the connection persistent in a
> closure, so I'd expect this to have very little effect.  It normally
> would only get called once per process.

Could have been something else I did - but I don't remember removing
anything else.

> > Memory::Size::Report breaks C::DBI if I try and report_size on
> > \%Class::DBI::
>
> How does it break?

The where condition in retrieve is empty and throws errors and about
half a dozen subroutines are redefined each time an object is created.

I have no idea why or how, but I managed to rule out everything else
before checking that it was Memory::Size::Report on \%Class::DBI::

> > Devel::LeakTrace won't report until the program
> > finishes and I'm currently running it for 12, 24 or 48 hours so that's
> > not much help.
>
> You need to make your testing procedure reproducible.  Ideally you would
> run a test that pounds on the thing for five minutes and then runs this
> report and quits.  You don't want to wait 24 hours for results.

Well usually the growth is visible in under an hour but I'd rather
test for much longer if this is going to be running for weeks.

Anyway - here's the good news - I've specified no cache in all my
set_sql calls, and regularly clear $dbh->{CachedKids} and now the
parent daemon has been sitting at 11MB since 10AM this morning - so
8.5 hours with no noticable increase in memory usage.

Woo!

A.



More information about the ClassDBI mailing list