Argus memory issues

[Carter Bullard]

Hey Russell,
Great suggestions, and we've got a few of them already in the code.

So, to get the speeds that we've been supporting in the research  
project,
I allocated a single size record for every flow.  That kept us out of  
the
kernel most of the time, but wasted a lot of memory.  argus-2.0 has a
fixed size record allocation scheme, and its flow model is very simple,
not allow for things like mpls or ipv6.

I'm converting argus-3.0 to be a bit smarter about memory, but it will
be in the kernel a bit more to do it.  I think it will be ok, as  
cycles have
not really been the problem.  Once I do this, then we can pick and
chose what objects to allocate.

The management records have the stats in them for existing memory
blocks used, how many have we gone through, the number of flows.
Just haven't gotten to printing them out yet.

I'll try to have this argus ready by Wed, going on the road again
tomorrow, so hopefully I'll get it finished by then.

Carter


On Aug 20, 2007, at 7:19 PM, Russell Fulton wrote:

> Here is a off the wall suggestion:  How easy would it be to wrap the
> memory allocation stuff so that it keeps track of the total amount of
> memory allocated  by category?  Then put a signal handler for, say  
> USR1,
> that syslogs the stats.  I guess the question boils down to how many
> places does argus allocate/free memory and are there neat categories
> that they slot into.  This could be tied to the .debug flag.
>
> Having an option that dumps the stats to sysylog periodically would  
> also
> be useful.  I think we should dump some of the stuff in the man record
> as well as the memory usage.
>
> Russell
>
> Peter Van Epp wrote:
>> On Mon, Aug 20, 2007 at 04:05:10PM -0400, Carter Bullard wrote:
>>
>>> Hey Peter,
>>> Oh lets adjust the timeout values, with all things back as you would
>>> normally run them.  The goal here is to understand if your just  
>>> churning
>>> through a lot of very short lived flows?  The current timeouts are
>>> pretty
>>> long (30 secs) and so if your getting 200K flows per second of low
>>> volume
>>> flows, then this should bring you back into a healthy range.
>>>
>>> If this is useful, then the workaround is very easy, as I can
>>> put in the logic to give flows with (pkts < 3) a zero timeout value,
>>> which
>>> should get your memory back.  That is a much easier fix than to  
>>> enforce
>>> a small memory foot print.
>>>
>>> So in this strategy, argus would hold any flow for the status  
>>> interval,
>>> hopefully that is a low number (5 secs is good, as 90% of flows live
>>> less than 2.5 seconds), and then for low volume flows, we  
>>> immediately
>>> deallocate the flow cache.
>>>
>>> If that is not good enough, we move to the next step, which is to  
>>> have
>>> different memory strategies for different flow types, currently  
>>> we have
>>> only one big flow cache no matter what happens.
>>>
>>> Carter
>>>
>>>
>>
>> 	With #define ARGUS_IPTIMEOUT 0 I still run out of memory:
>>
>> hcids:/usr/local/src/argus/argus-3.0.0 # ps auxwwww | grep argus
>> root     25722  4.3 92.4 4348872 3640432 ?     DLs  12:38   7:24  
>> argus -d -P 560 -i eth0 -i eth1 -U 512 -m -F /scratch/argus.conf
>> root     25980  0.0  0.0   3132   832 pts/0    S+   15:30   0:00  
>> grep argus
>>
>> Peter Van Epp / Operations and Technical Support
>> Simon Fraser University, Burnaby, B.C. Canada
>>
>