Mucking around with Devel::Leak::Object at work on Monday, I managed with very little effort to locate an object "leak" (we were loading a bunch of stuff in Apache child init handlers, instead of at startup time in the parent like we should have).
Immediately memory savings across 25 children? 600 meg! Multiplied by 5 boxes in the cluster. At the very least that should delay the need to add a new server to the cluster for a few months.
Inspired by the quick win, I've been trying to hook D:L:Object in deeper to the Apache server, to look for more leaking cases (our web app uses enormous amounts of ram, and despite it legitimately needing a lot for certain tasks, I'm thinking there's probably much more that isn't necesary).
Unfortunately, D:L:Object was originally written in the days when stringifying references to get information about them was still common practice, and as such if I try to load in the global bless/DESTROY hooks early, many many things explode violently due to IO/REF objects and stringification overloads in the 120meg of CPAN and company-specific modules that the server loads.
So with Ivor's permissions, I have taken over Devel::Leak::Object and done a complete rewrite using Scalar::Util instead of ref($object) string parsing, and adding support for things like single-param bless.
I've also covered a few extra edge cases using some evil code stolen from the ugly guts of Class::Autouse.
The new 0.90 release should appear on your CPAN mirror shortly. I encourage anyone interested in leak detection, caches, et al, to throw everything you have at it and see what you can still break.
I am very pleased that Adam is able to take my original concept of a leak tracer for objects and improve on my stringification approach. I'm also pleased that use.perl seems to have given this module recognition and publicity it deserves.
Re:Thank you!
Alias on 2007-08-31T02:21:19
Ack!:(
Indeed, I forgot to thank Ivor specifically for creating this module in the first place. I hadn't ever considered overriding global bless and hooking DESTROY as a viable method, but it's proved an excellent way to do it (although obvious things in Devel:: that do evil tricks like that should never be run on production).
