Catalyst::Controller::LeaktrackerLeakTracker Tutorial

Why use LeakTracker?

You have a Catalyst application that is consuming more and more memory over time. You would like to find out what classes are involved and where you may have cyclic references1. Why not try out nothingmuch ’s handy dandy Catalyst::Controller::LeakTracker

How to use LeakTracker?

Once you’ve plugged LeakTracker into your Catalyst application (see SYNOPSIS), you can easily get statistics via Catalyst::Controller::LeakTracker. Just create a new controller exclusively
for reporting on the objects that are not being garbage collected. Here is how:

package MyAss::Controller::Leaks;
sub BEGIN {
    use Moose;
    extends 'Catalyst::Controller::LeakTracker';
}
# redirect leaks/ to the report about memory consumed by each request
sub index : Path : Args(0) {
    my ( $self$c ) = @_;
    $c->forward("list_requests");
}
1
1

In effect, the controller above turns the URI $c.request.base/leaks into a report on the objects that still have references to them, and thus consuming memory.

How to Interpret the Results?

The results found at /leaks are per request. The results include the Catalyst actions requested and how much memory each consumed. One can “drill-down” on the request ID and get a report of all objects that the request has left lingering about. It’s tits, try it out for yourself.

When to Not Use LeakTracker?

In Production, because it adds a significant amount of overhead to your application.

Footnotes

1 On a related note, one could probably tweak this thing into a memory profiler as well.