argus 3.0.0 rc.28 memory leaks

[Carter Bullard]

Oh, no its just we're running gargoyle on much much much larger
networks than yours, and its memory is fine, in the types of ranges
you mention below.  I'll take a look at it in little while today.
(could be a scanner blowing through your network with a couple
million flows in a few seconds?)

Well, lets see how it goes!!!!

Carter


On Aug 31, 2006, at 3:13 PM, Gabriel L. Somlo wrote:

> On Thu, Aug 31, 2006 at 02:59:42PM -0400, Carter Bullard wrote:
>> I doubt there is a memory leak.  What is your FarStatusInterval  
>> set to?
>> (thanks for the code)
>
> umm, the default I guess. my config file has:
>
> ...
> ARGUS_FLOW_STATUS_INTERVAL=5
> ...
> ARGUS_MAR_STATUS_INTERVAL=60
> ...
>
> and that's the way they came, no changes there that I made...
>
> Now, after applying the patch I sent you, the argus process size seems
> to hover in the 570Mb virtual / 80Mb resident / 3.9% memory used
> range (after being up for 20 minutes), and no longer grows out of
> bounds like it used to before (and that's a good thing, as
> it is seems that argus can do more work with less hardware than we
> originally thought :) ).
>
> When you get a chance to look at the patch, please let me know if you
> think any of that stuff is wrong (I think I have a good defense for
> most of it :) :) ).
>
> Thanks much
> Gabriel
>
>
>> On Aug 31, 2006, at 2:39 PM, Gabriel L. Somlo wrote:
>>
>>> Carter,
>>>
>>> I've been running argus on a box with 1Gig of memory, and an
>>> Endace card to capture several hundred Mbps from our core. Argus
>>> becomes unresponsive in cca 20-30 minutes, because its memory
>>> image grows to the point where it starts swapping, and I can't
>>> get any more flow records from it beyond that point.
>>>
>>> I bumped the memory to two Gigs, and now it takes longer but it  
>>> still
>>> maxes out eventually and argus has to be restarted.
>>>
>>> I've started looking for possible memory leaks, and the attached  
>>> patch
>>> fixes the ones I found so far. I also fixed a couple of places where
>>> the code allowed a null pointer to be de-referenced (didn't see  
>>> those
>>> being tickled in a real-life situation, but better safe than  
>>> sorry :)
>>>
>>> Please apply, and I'll try to find more once these changes are in :)
>>>
>>> Thanks,
>>> Gabriel
>>> <argus-3.0.0.rc.28-mem.patch>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20060831/6168eaee/attachment.html>