|Problems? Is your data what you think it is?|
Tracking down memory leaksby scain (Curate)
|on Apr 13, 2005 at 12:18 UTC||Need Help??|
scain has asked for the
wisdom of the Perl Monks concerning the following question:
I have an application that parses largish tab delimited files (typically a few million rows) and writes out files suitable for bulk loading into a postgres database. Unfortunately, it seems to leak memory; after processing a few 100,000 lines, the processes starts to crawl, as swap gets used up and not long after that, the OS starts killing things.
When I realized that I had a memory leak, I figured I knew exactly where the problems was: I was using a few hashes to keep track of IDs that I was generating for a few of the tables. Simple enough--I tied those hashes to DB_File and the problem should be solved, right? Well, if it were, I wouldn't be writing this, would I?
Heading off to cpan, I found Devel::Leak, Devel::LeakTrace, Devel::Leak::Object and Devel::ObjectTracker. Unfortunately again, none of these seem to help much. Devel::Leak is quite low level, and so I don't really know how to use it. Ditto for Devel::LeakTrace. If anyone has suggestions for how to use it for finding the leak, I'm all ears/eyes.
Devel::ObjectTracker seemed promising. It is well documented and several configurable options, including allowing it to track hashes and arrays in addtion to objects. Unfortunately (I am getting tired of using that word), it seems to ignore all the settings for the options, and doesn't print anything other than table column headings in its output.
Devel::Leak::Object seemed to also have promise. When using it, it overloads the bless function to allow tracking of creation and destruction of objects. While this worked, it only showed two objects remaining at the completion of the main loop: one is a small config-fetching object that I could easily destroy before the loop, but there is no way that is leaking, and the other is the object that handles IO, and the author of that object insists that it can't be leaking either (there are no package variables in the object).
So, if anyone has suggestions for where to go from here, I'd really appreciate seeing them.