Interesting things to look for in the current 3.0 code ...
Peter Van Epp
vanepp at sfu.ca
Fri Aug 17 10:31:21 EDT 2007
On Fri, Aug 17, 2007 at 01:54:03AM -0400, Carter Bullard wrote:
> Hey Peter,
> Well my leaks are not real, at least on my Mac, or on the 64-bit
> intel machines,
> but my traffic loads are not really high, so I could have a very slow
> memory issue.
> I'll try to replicate this tomorrow on some other hardware that I
> have. I did make
> some significant changes just now, that could affect both the
> threaded and non
> threaded versions. I changed the way we assign timeout values to
> each flow. It
> was possible, although it appeared highly unlikely, that individual
> flows may
> try to use idle timeouts in the 1000's of seconds (this maybe your
> old timestamp
> issue, but no promises) or possibly 0, which could put them in a bin
> that
> may never time out (except when a matching packet hits that cache
> then it
> would come back into the system). well anyway, I limited the range
> of timeout
> values, and possibly that could have an effect. I've just now uploaded
> new argus and clients.
>
> I'm going to let argus run all night on my mac running under
> mallocdebug, which
> is not a bad program. At least it showed me that I leaked 32 bytes,
> but thats it so
> far ;o)
>
> Carter
>
Mine look pretty real but may be just my machine :-). Yesterday's
argus without threads or user data:
ps auxwwww | grep argus
root 6698 1.5 96.6 4479328 3802756 ? DLs Aug16 12:11 argus -dJR -P 560 -i eth0 -i eth1 -m -F /scratch/argus.conf
and ra on the Mac isn't getting any data. I'm just about to try the new argus
and clients and see what happens.
Peter Van Epp / Operations and Technical Support
Simon Fraser University, Burnaby, B.C. Canada
More information about the argus
mailing list