rasqlinsert crashing

Mike mike-arguslist at tiedyenetworks.com
Wed Apr 21 14:24:55 EDT 2010


carter at qosient.com wrote:
> Hey Mike,
> For mysql support, you should use the development version of the clients, as there have been quite a number of bug fixes there.
> 
>    Http://qosient.com/argus/dev
> 
> The rasqlinsert() ihere does what you would like.
> 
> Carter 
> 

Thank you for the pointer, seems more stable now. Using rasqlinsert with
the %Y_$m_%d is handy for keeping daily flow tables, and man do they get
big I had no idea we had so many flows. My tables are multi-gigabyte
already, and most sql queries I run against it are revealing peformance
problems I never thought about. In one instance, a simple perl script
using DBI::Mysql just hangs every time on "prepare("SELECT
saddr,daddr,bytes ..." and grows to monstrous virtual memory
proportions. And I also notice there's no indexes in the autogenerated
tables of rasqlinsert, which I assume (?) is intentional for performance
reasons?

	The performance of my host, under argus/rasqlinsert, seems awfully bad
and out of line with my experience in other mysql based apps even with
big tables like this. I have been doing some digging trying to see about
why this might be so and so far I haven't come up with much. One issue I
did notice however, was that rasqlinsert seems to have some calls to
localtime/getlocaltime in the wrong place, resulting in about 170 calls
to stat64(/etc/localtime) and gettimeofday for every argus packet
received. It also seems to draw too much in from ratop, which may have
helped speed development but which also makes it more difficult to
follow. It also has trouble (all argus client progs do) with dying when
sent a kill, necessitating a the magic -9 sword. Of course, not to look
a gift horse in the you know what, I am wondering wether sql really is
going to be preferable to straight argus
files for large #'s of flows?

Mike-





More information about the argus mailing list