Core dump in bpf.

[Carter Bullard]

If argus got that far into the code, its not a bpf patch problem.
The rasort() problem is an interesting one, and I'm not sure why
all of a sudden it has reared its ugly head, but its my bug.

I think we got your problem snuffed in beta.6.

When we get that many flows, which I estimate you got ~ 1.4M of
them, we don't process them as fast as we should.  Flows end up
in the process queue for 3-4X their timeout values and that
I believe, generates some garbage collection problems.  Just a
theory that I have.

I'll make one more change for the large flow set problem, and
we'll see how that goes in beta.6.

Carter

Carter Bullard
QoSient, LLC
300 E. 56th Street, Suite 18K
New York, New York  10022

carter at qosient.com
Phone +1 212 588-9133
Fax   +1 212 588-9134

> -----Original Message-----
> From: Scott A. McIntyre [mailto:scott at xs4all.nl]
> Sent: Tuesday, February 20, 2001 8:01 AM
> To: Carter Bullard
> Subject: Re: Core dump in bpf.
> 
> 
> >    Hey Scott,
> >       Did we run out of memory?  Any messages in the
> >    messages file?  User Data len of 256 should be OK.
> >    I test constantly with 128, so I have a better feel
> >    for that number, but 256 should be OK.
> > 
> >    I'll keep looking,
> 
> The system has a gig of ram, and a gig of swap, and there 
> were no other
> log entries or signs that it ran out of memory...but I'll certain
> continue looking.  However, I sense it's something with the 
> bpf patch or
> somewhere else in that bpf code as rasort core dumps every time now...
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20010220/2e3e0462/attachment.html>