[Snort-users] Snort and MySQL
roman at ...438...
Mon Jan 22 16:01:32 EST 2001
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).
On Mon, 22 Jan 2001, Karl Lovink wrote:
> What if I configure snort to use ORACLE DBS and patch ACID so that it
> 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,
> -----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.
> > Well I got my problems fixe (thanks all) and now have snort logging to
> > remote db. Encountered an interesting thing. I have consoles with me
> > into both boxes and I'm running top. Then I use acid to view data in
> > and notice that while mysql is busy handling the query, snort drops
> > 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%
> > while handling the query, then falls back to less than 4%. Given a
> > I'll go through the ruleset and retailor for our network based on what
> > see and what we don't really care about to try to reduce the load on
> > sensor.
More information about the Snort-users