Ashley, nothing is going to change in the code unless YOU are willing to work the problem.
We've bounced this back and forth a couple of times, and you've never responded to the questions about the # of hosts present on and the # of hosts being accessed from your network. (Yes, you indicated a /20 and /24, but how many of the 17K are active? How many active sessions?? etc.) As somebody pointed out, one busy Kazza user can access 40K hosts searching for a rare file. Each host eats up a fairly amount of memory, because we have to track all of the 64K possible ports. Action items: 1. Post the data from textinfo.html as close to when it dies as possible... I'm interested in Host Memory Cache Limit.....#define MAX_HOSTS_CACHE_LEN 512 Current Size.....52 Maximum Size.....69 # Entries Reused.....1099 and Host Hash counts Actual Hash Size.....512 Stored hosts.....20 [3 %] Purge idle hosts.....Enabled Purged hosts.....1151 Maximum hosts to purge per cycle.....512 DEFAULT_MAXIMUM_HOSTS_PURGE_PER_CYCLE.....512 2. Run under gdb and post the bt full trace so we can see where it's dying... 3. Try using the large network flags ... -g | --track-local-hosts, -z | --disable-sessions and/or -C | --large-network (the first 2 are documented in docs/FAQ). 4. You can use a sneaky trick to estimate how big the host population ntop is monitoring is by using rrd! (Turn it on in the plugins menu and make sure to enable hosts - remember you may have to create the directory and give the -u user w/r access to it). If you delete all the files 'tween runs, then when ntop dies, the # of entries in the rrd/hosts directory is an upper bound on the # of hosts ntop is monitoring. If you subtract the # of purged items (Purged hosts.....) you grabbed from info.html just before it dies, that will give you a lower bound. -----Burton -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Ashley Gates Sent: Thursday, January 23, 2003 4:52 PM To: [EMAIL PROTECTED] Subject: [Ntop] Hash size / memory gobbler I've taken the advice to compile and use the latest source to ntop. I now currently run: ntop v.2.1.55 MT (SSL) [i686-pc-linux-gnu] (01/21/03 01:32:38 PM build) The hash size problem still remains, now it takes even longer for ntop to eat 1 gig of RAM and seg fault. Previously it was 30-40 minutes, it now takes over an hour. Good work so far on getting this gremlin under control, but alas I cannot trust it for what it needs to be for me.. :-) I will continue to compile the latest source once a week and keep updating on the issue. Thanks, Ashley Gates Director of Network Operations Atlanta Broadband, Inc. http://www.atlantabroadband.net Office: 770.794.0767 _______________________________________________ Ntop mailing list [EMAIL PROTECTED] http://listgateway.unipi.it/mailman/listinfo/ntop _______________________________________________ Ntop mailing list [EMAIL PROTECTED] http://listgateway.unipi.it/mailman/listinfo/ntop
