Listen to Benny. Luca does some Gigabit stuff, but Benny routinely monitors (one of if not) the largest network(s) I'm aware of an ntop user monitoring.
20KB is a very rough estimate, but that doesn't include sessions. A busy VPN server w/ 100s of long running sessions will have a much bigger footprint. Same for any protocol with persistent sessions. There's also a large fixed chunk of memory used - look at textinfo.html. ntop is typically pretty close to memory bandwidth limited. So PC100 will hurt you - the limit on bandwidth to/from memory (there's just no way to mind-meld PC3200 to that 550MHz cpu). Since ntop doesn't take advantage of P4 beyond the routine gcc stuff, when we talk about 'fast' cpu, that's often really short hand for the things that come with that fast processor: a fast memory subsystem - big caches, fast access, lots of memory bandwidth. I'd add * Don't run ANYTHING else on the ntop box. * Make sure you are NOT using --disable-instantsessionpurge. While it's the RIGHT thing, you can't afford it. * If you have multiple NICs, think about a dual processor box. While ntop's packet processor isn't multi-threaded, everything else, including capture can split itself among the processors. Hence, SMP can really help - this means that viewing web pages doesn't kill monitoring and vice versa. Don't really know about hyperthreading - it would depend on the pattern of stalls... * Think about filtering and/or --track-local-hosts - why do you really care about your outside traffic? Check your swap stats - I routinely advise users that once you start swapping you are dead. If purge takes too long, while it's holding certain locks, it can kill things - so much gets backed up that ntop can't recover in time for the next purge cycle which is a vicious spiral. There are a couple of processes in ntop that (must) walk the entire memory structure - beyond purge, most of the others occur when you create web pages to view the network stats (even if ntop only shows you 100 entries, it frequently has to walk the structure to create the array to sort to get those 100). The bigger the network, the longer this takes... -----Burton > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of > Horta, Benny > Sent: Monday, May 24, 2004 9:19 AM > To: '[EMAIL PROTECTED]' > Subject: RE: [Ntop] scaling for a class B > > > Not enough, you need the fastest CPU you can afford and about 2gigs of ram > to start out on a large B network. You need to use the -x option to limit > the number of hash entries, typically -x 8000 or -x 16000 should be good > testing points, I would really go for a 3.0 P4 with 2 gigs of ram > for a good > class B ntop box to start. You might want to disable session > tracking if CPU > is still an issue. > > -----Original Message----- > From: Greg Redder [mailto:[EMAIL PROTECTED] > Sent: Thursday, May 20, 2004 12:18 PM > To: [EMAIL PROTECTED] > Subject: [Ntop] scaling for a class B > > > > I'm curious if anyone is using ntop to monitor an entire class B network > and if so, what number of hosts you are seeing, and how you are configured > both in ntop and hardware. > > We have several sites we monitor and one of them is a classB network. We > only have about 768Megs in a 550Mhz machine. We've turned off dns > lookups, we only track local hosts and we don't do session tracking. > However, the box just can't keep up. We've seen upwards of 30,000 hosts > on that network and at 20K each, that alone should take 600Meg, but it > seems to be running out of memory before that. I'm sure there's some > upper memory limit that can handle it or maybe I'm missing something else. > We aren't doing any filtering at this point, but that may be our only > option. > > Thank you > --Greg Redder > Network Analyst > Colorado State University > > > ================================================================== > ========== > === > Greg Redder Academic Computing & > Networking Services > Colorado State University, ACNS Phone:(970)491-7222 FAX: > (970)491-1958 > 601 S. Howes, Room 625 E-mail: [EMAIL PROTECTED] > Fort Collins, CO 80523 PGP > Fprint:299F83B58A72BE7428E064E801749C69FFA537C6 > ================================================================== > ========== > === > > _______________________________________________ > Ntop mailing list > [EMAIL PROTECTED] > http://listgateway.unipi.it/mailman/listinfo/ntop > _______________________________________________ Ntop mailing list [EMAIL PROTECTED] http://listgateway.unipi.it/mailman/listinfo/ntop
