in reply to Re^7: Massive Perl Memory Leak
in thread Massive Perl Memory Leak
I was saying that the script is 100 KB, not 100 K-lines. :P And ur right about the trim down artifacts. $session is a ref to the object as created in another namespace. I moved that into main for the test script. %$result6 is another experiment. The original code is || seperated.
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re^9: Massive Perl Memory Leak
by BrowserUk (Patriarch) on Jun 18, 2007 at 22:41 UTC | |
The singleton's should as well be cloned and not be able to touch each other. I said I suspect but cannot prove. Without 1000 SNMP devices (or even one I could call 1000 times) all I can do is speculate. I agree it shouldn't happen, but are there any occasions or circumstances where a variable becomes shared without explicit sharing? Well, take the example of any parameters you pass to your thread code on the threads->create(), you don't need to share those. But that's a special case. How about your leaker3.pl above. You create your queue in the main thread and never share it:
but there you are using it inside the thread subroutine:
If that was shared without explicit instruction, what else was? Do me a favour and try this. All the non-blocking SNMP code is derived purely from the docs, which I may have misundertood. It compiles clean but is otherwise untested so it may require a few tweaks. It is basically the third option I mentioned above that use threads to rescue the calling code from the binds of the underlying event-driven state machine.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] [d/l] [select] |
by wagnerc (Sexton) on Jun 19, 2007 at 00:48 UTC | |
Ok the script completed. It only used about 300 MB of memory. As I expected the non CIDR devices returned nothing. :) I'ld be interested to see how the nonblocking calls behave within worker threads.. Hmm. Another thing I tried. In my leaker3 I moved the require Net::SNMP down into the entrypoint as eval "require Net::SNMP"; figuring that way there would be *no* objects to clone since the entire module wasn't instantiated yet. Doing that used up even more memory than require'ing it at the top of the script. :P | [reply] |
by wagnerc (Sexton) on Dec 14, 2010 at 02:40 UTC | |
| [reply] |
by BrowserUk (Patriarch) on Jun 19, 2007 at 02:17 UTC | |
Duh! I'm being dense. Simply defer the non-CIDR attempt until the CIDR attempt fails. Right there in the callback for the first attempt we have all the information available to make the re-attempts. How does this go?
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] [d/l] |
by BrowserUk (Patriarch) on Jun 19, 2007 at 01:44 UTC | |
Darn. Didn't think of that. Looks like you're back to one of the other two options ;( Or, you could try NSNMP::Simple with your threaded/synchronous requests approach. A quick look at the source shows it be be pure perl and doesn't use any globals. There are a couple of lexical globals used via closure, but they should be relatively safe. The author says it's not ready for prime time, but maybe it will just work for you. Worth a shot. Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |