Hmmm. Simple way, make your ntop host "see" many networks, then ping every ip address on each network. Or, remove the 1024? Host limit per network, and create a /16 network and start pinging away. Basically just manifest a bunch of hosts - if you can manifest a bunch of sessions as well, the would be better!
I'm still at 435MB with "only" 2,300 hosts and 7,500 sessions. Roughly same memory as when is was 30K hosts and 30K sessions. Also, I THINK my cpu util issue MAY be due to a loop condition in event.c - but not sure if it's your event.c or libevent event.c. I'm on 1.4.11 libevent, but they have a 2.0 x release that's supposed to be much better at various things. If I restart this instance right now I'd bet it would be < 100MB and < 5% cpu. I'll send you some gdb output privately. TIA! Gary ________________________________ From: [email protected] [mailto:[email protected]] On Behalf Of Luca Deri Sent: Thursday, June 25, 2009 4:56 PM To: [email protected] Subject: Re: [Ntop] Race condition in 3.3.10? Gary how can I reproduce this meMory issue? Luca Il giorno 25/giu/2009, alle ore 23.06, "Gary Gatten" <[email protected]> ha scritto: Ps - I have trace level at 5 and nothing interesting in the logs. Also, it *appears* as though memory isn't being freed. I have a/v scanners that cause ntop to see upwards of 30,000 hosts for brief periods every 4 hours. Obviously it must allocate memory for these, but after they are purged the memory should be released right? I don't have "purge cache" or whatever enabled - I can't get it to compile with that option set. ________________________________ From: [email protected] To: [email protected] ; [email protected] Sent: Thu Jun 25 15:54:37 2009 Subject: [Ntop] Race condition in 3.3.10? STILL trying to track down high CPU load since the upgrade to 3.3.x. This morning one of my nTop instances that normally runs < 10% (even on 3.3.10) jumped to about 50%. It might go even higher but I have another instance also running at 50% - it was 90% before this one jumped. Anyone, the netflow thread is usually number 5 - and in this case is as well. The thread taking all the CPU is number 1, which is typically the "main" process. Thread 1 and 5 are usually the busiest, but when thread 1 is taking roughly 10x the cpu as thread 5, something is wrong. I'm thinking it was running along all fine and happy until some set of conditions occurred that caused it to freak out - some sort of race / locking issue? Nothing changed "significantly" in my network to account for the 5 - 10 fold jump in util for this instance. Roughly the same number of flows, pps, hosts, sessions, etc. It was 5%, then bang - 50% and been there ever since... I CAN attach to this with gdb and look at stuff - if someone smarter than me can assist. I can make since of SOME of the gdb output, but not having a strong development / debugging background is limiting me. TIA! Gary "This email is intended to be reviewed by only the intended recipient and may contain information that is privileged and/or confidential. If you are not the intended recipient, you are hereby notified that any review, use, dissemination, disclosure or copying of this email and its attachments, if any, is strictly prohibited. If you have received this email in error, please immediately notify the sender by return email and delete this email from your system." "This email is intended to be reviewed by only the intended recipient and may contain information that is privileged and/or confidential. If you are not the intended recipient, you are hereby notified that any review, use, dissemination, disclosure or copying of this email and its attachments, if any, is strictly prohibited. If you have received this email in error, please immediately notify the sender by return email and delete this email from your system." _______________________________________________ Ntop mailing list [email protected] http://listgateway.unipi.it/mailman/listinfo/ntop <font size="1"> <div style='border:none;border-bottom:double windowtext 2.25pt;padding:0in 0in 1.0pt 0in'> </div> "This email is intended to be reviewed by only the intended recipient and may contain information that is privileged and/or confidential. If you are not the intended recipient, you are hereby notified that any review, use, dissemination, disclosure or copying of this email and its attachments, if any, is strictly prohibited. If you have received this email in error, please immediately notify the sender by return email and delete this email from your system." </font>
_______________________________________________ Ntop mailing list [email protected] http://listgateway.unipi.it/mailman/listinfo/ntop
