Argus memory issues

[Carter Bullard]

OK, I have an argus with a completely different memory strategy
that can be tested, however, it doesn't generate usable output yet.
I will try to get it ready for tonight, or early tomorrow.  Would
anyone be interested in running it for a while, just to see what the
memory use looks like?  No client involvement, just hooking it up
to a packet hose, and watching what it does (may core, but so
far so good).

This should cut memory use for low impact flows to 10-15% of
what it is now, possibly less than argus-2.0, for some traffic mixes.
It will be in the kernel a bit more than earlier memory models, but
should work.

Carter


Peter Van Epp wrote:
> On Mon, Aug 20, 2007 at 01:39:21PM +1200, Russell Fulton wrote:
>   
>> Hi All,
>>
>> Sorry, I'm a bit late to the party :)
>>
>> I have just restarted argus on the sensor that I have been having
>> trouble with and in a couple of hours one instance of argus has grown to
>> well over 200MB (this one is collecting content).  One on the same
>> machine just collecting flow data is now at 99MB  both are still increasing.
>>
>> No wonder the box is starting to swap.
>>
>> Do we have any idea when this bug crept in?  So far as I can tell I
>> started having problems less than a month ago roughly coincident with
>> installing the 3.0.0.0 release veriom.  Previously I had been running
>> RC40 without problems since February.   Yesterday I went back to RC40
>> and I am having the same trouble.
>>
>> I wonder if there is some new application that is tickling this bug in
>> argus -- e.g. changes to SKYPE or something like that that both Peter
>> and I would see but commercial folk would block.  I'd love to blame
>> storm worm but we have not seen much of it here.
>>
>> One other observation: argus keeps *all* its memory in physical memory
>> -- it does not get swapped out so this is killing snort which is getting
>> swapped aggressively.
>>
>> Russell
>>     
>
> 	That has been my experience too. I tried going back to versions that
> I swear were working fine, but now they exhibit the same problem and I don't
> know why. There may be a traffic issue though, my 2.0.6 production system 
> while not eating memory (it has been at 256K since June last year as I recall)
> is taking a long time in perl post processing, but I can't find any obvious
> reason why. Scanning looks reasonably normal, traffic isn't overly high. I too
> am wondering about storm because I too am not recognizing anything I think
> is storm traffic (things have been quiet on the infection front for months)
> and I expect I have storm infections here that I'm just not seeing :-).
>
> Peter Van Epp / Operations and Technical Support 
> Simon Fraser University, Burnaby, B.C. Canada
>
>