Update of /export/home/ntop/ntop
In directory jabber:/tmp/cvs-serv26912
Modified Files:
ntop.h globals.h main.c initialize.c hash.c webInterface.c
ntop.8 ntop.html ntop.txt
Log Message:
Help w/ ntop performance problem in purge for LARGE hash sizes.
The problem is the time it takes to purge inactive hosts. Currently, ntop purges
Help w/ ntop performance problem in purge for LARGE hash sizes.
The problem is the time it takes to purge inactive hosts. Currently, ntop purges
idle hosts up to 1/3 of the total # of hosts in the hash. During this period,
which can be several seconds for even a moderatly busy network (e.g.
IDLE_PURGE: Elapsed Time is 10.67 seconds, 120 hosts deleted, 0.089 per.
on a PIII-1GHz machine) the CPU usage may reach 100%.
As long as we're not losing packets, the time it takes to purge is really irrelevant.
Repeat: This is NOT a problem, unless the purge holds certain mutexes for such
a long time that ntop locks up (actually or effectively).
Up to a point, the trade-off is memory used (to hold "old" host data) vs. how much
time it requires to purge (how aggressive the purge is).
This patch is to make purge LESS aggressive, by limiting the per cycle purge to
the lesser of 512 hosts OR 1/3 of the hash size.
This patch isn't a perfect answer, but reducing the per cycle purge time
can give substantial real-world benefits for LARGE ntop installations.
The rest is optional, to dynamically scale the #s to keep the purge time limited
in a way that reflects the environment (elapsed time) not just a fixed #.
Perodic log message:
IDLE_PURGE: Elapsed Time is #.## seconds, # hosts deleted, #.### per.
Dynamic adjustment message:
IDLE_PURGE: Adjusting maximumHostsToPurgePerCycle from # to #...
-----Burton (ref 147)
Thanks to Benny Horta of Miami-Dade Schools for testing a number of versions
of this patch!
_______________________________________________
Ntop-dev mailing list
[EMAIL PROTECTED]
http://listgateway.unipi.it/mailman/listinfo/ntop-dev
