[Snort-users] Snort and MySQL

Roman Danyliw roman at ...438...
Mon Jan 22 16:01:32 EST 2001


Karl,

I would suspect that using Oracle (or Postgress) may solve some of these
problems for they both support real locking granularity.  Alas, locking
granularity (among other things) is a trade off with speed.  One of the
reasons that MySQL was so fast was its coarse locking.

In reference to patching ACID, this is exactly what I am working on right
now: a DB abstraction which would allow for different underlying databases
(e.g. MySQL, Postgress, Oracle, ODBC).  

cheers,
Roman

On Mon, 22 Jan 2001, Karl Lovink wrote:

>
> What if I configure snort to use ORACLE DBS and patch ACID so that it
> can
> use ORACLE. Is that problem that solved. I face the same problem and it
> getting worse. This because my database is getting larger and larger.
>
>
> Kind regards,
> Karl
>
>
> -----Oorspronkelijk bericht-----
> Van: snort-users-admin at lists.sourceforge.net
> [mailto:snort-users-admin at lists.sourceforge.net]Namens roman at ...438...
> Verzonden: maandag 22 januari 2001 15:55
> Aan: Kevin.Brown at ...1022...
> CC: snort-users at lists.sourceforge.net
> Onderwerp: Re: [Snort-users] Snort and MySQL
>
>
> This is at least partially related to MySQL internals.  MySQL currently
> only supports table level locking.  When ACID makes a query,
> MySQL locks the table for reading.  Thus, when Snort attempts
> to write, it will not be able to get a lock (on the entire table)
> and remains blocked waiting for the ACID read to finish.  Hence,
> the Snort utilization percent will drop.
>
> This phenomenon will be resolved when Snort is multi-threaded.
> I would envision at a minimum that the detection core and the
> the output facilities/plug-ins would be seperate threads.
>
> Roman
> 
> > Well I got my problems fixe (thanks all) and now have snort logging to
a
> > remote db.  Encountered an interesting thing.  I have consoles with me
> logged
> > into both boxes and I'm running top.  Then I use acid to view data in
the
> db
> > and notice that while mysql is busy handling the query, snort drops
from
> 98%
> > to 17% cpu utilization, then goes back to 98% after mysql finishes the
> > query.  In the same time mysqld goes from 4% utilization to 98%
> utilization
> > while handling the query, then falls back to less than 4%.  Given a
few
> weeks
> > I'll go through the ruleset and retailor for our network based on what
it
> did
> > see and what we don't really care about to try to reduce the load on
the
> > sensor.
> >





More information about the Snort-users mailing list