What's your traffic flow - is the a DLS/Cable/dial w/ a few hosts?

Thoughts:

1. Get a real system... Doesn't have to be a P$-3.06g w/ 2GB of ram, but
something a little beefier - add memory - it's cheap today ...  After the OS
and all the other cr*p running, how much is really available to ntop w/o
swapping - that's the critical measurement.  Once ntop starts to swap,
you're dead - walking the tables to compute throughput etc. puts a big load
on the system.

2. What's the memory usage stats look like.  Look at textinfo.html or grab a
newer version and post the problem report data - it has the data on how
memory is being used...

For example (mmaped are the large single allocations, tend to be the big
structures @ startup and don't change much over time.  data segment
allocations are the little things, esp. per host...)

Memory allocation - data segment

arena limit, getrlimit(RLIMIT_DATA, ...).....-1
Allocated blocks (ordblks).....2145
Allocated (arena).....15659676
Used (uordblks).....14923220
Free (fordblks).....736456


Memory allocation - mmapped

Allocated blocks (hblks).....9
Allocated bytes (hblkhd).....10817536
...

How many hosts are being monitored?  That contributes a lot to memory usage:

Host/Session counts - Device 0 (eth1)
Actual Hash Size.....1024
Stored hosts.....646 [63 %]
Sessions.....2
Max Num. Sessions.....73

Host/Session counts - Device 1 (eth2)
Actual Hash Size.....512
Stored hosts.....53 [10 %]
Sessions.....13
Max Num. Sessions.....86

Host/Session counts - Device 2 (NetFlow-device)
Actual Hash Size.....32
Stored hosts.....1 [3 %]
Sessions.....0
Max Num. Sessions.....0

That's ~15MB for 700+ hosts ... about 13KB per.  And that fits real
comfortablly in my system...

  2:57pm  up 9 days, 18:36,  1 user,  load average: 3.00, 3.00, 3.00
57 processes: 52 sleeping, 5 running, 0 zombie, 0 stopped
CPU0 states: 99.1% user,  0.3% system,  0.0% nice,  0.1% idle
CPU1 states: 97.0% user,  2.2% system, 97.1% nice,  0.1% idle
Mem:   577976K av,  530200K used,   47776K free,       0K shrd,  106688K
buff
Swap: 2088408K av,    2128K used, 2086280K free                  283632K
cached

(The load is 2x [EMAIL PROTECTED])

3. Don't track external hosts (use the flag to turn it off).  People
connecting to you can add a big # of hosts you may not think of.


-----Burton

   |\      _,,,---,,_       "If I purr, you must have fed me.
   /,`.-'`'    -.  ;-;;,_    If the network purrs, it must
 <|,4-  ) )-,_..;\ (  `'-'   be ntop!"   -----Pixel
   '---''(_/--'  `-'\_)




-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Juan
Puchalski
Sent: Sunday, March 09, 2003 12:44 PM
To: [EMAIL PROTECTED]
Subject: [Ntop] NTOP eating memory without stopping



Hello,

I've read the previous threads concerning memory eating and hash sizes, and
the information regarding a solution/fix to the supersizing of NTOP is
pretty scarce.

I run 2.1.55 (sourceforge), using a Pentium MMX 166, 84 megs of RAM. I run
it with the following command line:

ntop -c -u ntop -m xxx.xxx.xxx.xxx/24, 192.168.0.0/24 -w 8080 -i eth0,eth1

I use the sticky hosts option since the hosts in my network generally
connect for short periods of time and then dissapear, so dynamically purging
the hash doesn't work for me.

After about 5 minutes, NTOP drives the server load to about 2.8, and if left
unattended it can reach 25. I would think this is a lack of hardware power
issue, but I've managed various times to get ntop to use a very small memory
footprint (12M) with this same command line during a high day traffic and
keep that footprint for over 48 hours. I haven't found the right formula so
far to be able to repeat this behaviour constantly.

I tried using a SQL server to store host data, but it still drives memory
usage thru the roof.

What do you recommend to do in my case?

Juan Puchalski

_______________________________________________
Ntop mailing list
[EMAIL PROTECTED]
http://listgateway.unipi.it/mailman/listinfo/ntop

_______________________________________________
Ntop mailing list
[EMAIL PROTECTED]
http://listgateway.unipi.it/mailman/listinfo/ntop

Reply via email to