FOLLOWUP: oddities with ramon

[eric]

On Fri, 2005-04-22 at 20:33:21 -0700, Peter Van Epp proclaimed...

> > I've checked /var/log/messages for any signs of memory trouble and none
> > are present. I've also run top in another session and ramon will take
> > anywhere from 103M to 207M while it's crunching numbers.

Bah, that's nothing! We usually suck up about 900MB. Don't forget, get rid
of that rasort(1), else you'll need about twice the amount of memory.

> > ramon -nnnr argus.[date] - net 172.16.1

Try using the -R flag; I think that's what Carter would say.

> 	How much data are you trying to analyse here? An ls -l of argus.[date]
> would probably be useful. I expect you are running out of memory or in to a 
> size limit in the clients. I remember Carter indicating some size limits that 
> Eric should try increasing when argus was seg faulting on him (they should 
> be in the archive but I'm not sure how you would find them) but I think they 
> were for argus_bpf rather than the clients (but they may apply to both). I
> just started:

[ Hey Peter! Hope all is well ]

Yes, there's hard memory limits in the *BSD kernels that you can tweak. For
FreeBSD, check LINT. Basically you do this...

options MAXDSIZ="(1792*1024*1024)"      #added for rasort! 20040430
options DFLDSIZ="(1792*1024*1024)"      #added for rasort! 20040430
options MAXSSIZ="(1792*1024*1024)"      #added for rasort! 20040430

Then crank maxusers. Also, comment out KTRACE; it's just adding latency to
any system calls.

We're looking at about 14GB every day (compressed). We don't use argus, we
use the commercial version. But proper system maintenance will help you no
matter what. 

- Eric