in reply to leak detection in other (non-perl) processes

In this case, it would be better to not have to reinvent the wheel, but I have not been able to find any such algorithms or modules via searching the web, cpan, etc.
I'm pretty sure I've used tools in the past that could do exactly like that.
monitoring to be handled by a perl script.
Ah, well, that's the killer.

I'm 100% sure the tools I've used were not written in Perl.

  • Comment on Re: leak detection in other (non-perl) processes

Replies are listed 'Best First'.
Re^2: leak detection in other (non-perl) processes
by apprentice (Scribe) on Mar 23, 2012 at 18:45 UTC
    Yes, even if I can't find something written in perl, I can easily convert from another language.


    "Peace, love, and Perl...well, okay, mostly just Perl!" --me

    Apprentice

      I'm not exactly sure I understand what you want to achieve (finding out there are leaks vs. what exactly they are caused by), but as you're talking about non-Perl processes, it sounds like you're looking for generic tools like valgrind.

      Due to the complexity of the tool, however, it's beyond me why you would want to rewrite it in Perl (not to mention the ensuing performance issues...).

        OK, let's say that I want to monitor process X, which could be affected by repeatedly killing process Y. That is, I am attempting to 'induce' leaks.

        So, I get a baseline, like say '17' open file descriptors (FDs) for process X.

        Then I loop for 'n' iterations, killing process Y, waiting a bit, getting current FD count, storing it, next.

        Now, I may have a list that looks like one of the following:

        For example, lets use file descriptors, here are some lists of possibl +e values A = 17 17 17 17 17 17 17 17 17 17 17 17 17 17 17 17 17 17 17 17 17 17 +17 17 B = 17 17 17 17 17 17 17 17 17 17 17 17 16 17 17 17 17 17 17 17 17 17 +17 17 C = 17 17 17 17 17 17 17 17 17 17 17 17 17 17 17 17 17 17 17 17 17 17 +17 25 D = 17 20 17 20 17 20 17 20 17 20 17 20 17 20 17 20 17 20 17 20 17 20 +17 20 E = 17 20 34 29 36 22 18 25 19 19 19 43 52 37 28 19 17 17 17 20 17 27 +36 47 F = 17 20 23 26 29 32 35 38 41 44 47 50 53 56 59 62 65 68 71 74 77 80 +83 86 G = 17 20 20 26 25 26 30 34 38 41 44 39 42 46 50 58 52 55 55 55 55 56 +59 58 Here are some of the thoughts I have jotted down: Example A: not a leak, easy to determine, never changes Example B: not a leak, almost never changes, value only ips for a moment, may reset low value, but does not reset average value (int), so does not represent a leak, easy to determine Example C: does not appear to be a leak, almost never changes, only appears at end of data, low enough value should not change average value much, would statistics help here, to show it as an outlier? may be able to use position as an indicator, no change ever until final position out of n positions would show it to be an outlier (however, a single change earlier that did not reset could be a very slow leak, potentially, requiring more time to evaluate) NOTE: a single change anywhere, that resets, is not a leak Example D: not a leak, changes regularly, up and down the same amounts, harder to detect, can notice that the current number repeatedly drops to the low number (or thereabouts) and the current number only climbs to the max number or thereabouts (can keep average low and average max as well as running average), maybe keep counts of individual numbers or 'buckets' as well, but still possible to determine NOTE: Related, but IS a leak of some sort, would be when it always drops back to the low or thereabouts, but always or evetually always climbs to a higher max Example E: not a leak, changes regularly, but by varying amounts, ends on a high note, so would have to be mindful that it drops back down to or near the low frequently (frequency/counts) and recently (positional) Example F: IS a leak, changes regularly, always up, but by varying amounts, easy to detect (can also count increases, decreases if it helps the other cases) Example G: IS a leak, changes regularly, not every time, sometimes decreases, but relatively few decreases, continued upward trend NOTE: Should continually check that the PID of each process does not change, else the values are no longer any good!!!in which case, they will almost certainly reset to lower values, perhaps climbing again Other considerations: Want to consider the slope, percentage-wise as well as absolute...???


        "Peace, love, and Perl...well, okay, mostly just Perl!" --me

        Apprentice