Well, it usually takes atleast 15-20 minutes to get results back on a
database that has many alerts in it.  The system itself is dual pentium
4 1 GHZ with 1 GByte of RAM.  I have been talking to a few people and
they mentioned trying to update the memory space for which postgres uses
by tweaking freebsd and also postrgesql.conf itself?  I have done some
vacuuming on the database itself.  I guess I just need to optimize the
speed of the system as much as possible.


Jeremy 

Dann Corbit wrote:
> 
> > -----Original Message-----
> > From: Jeremy Hefner [mailto:[EMAIL PROTECTED]
> > Sent: Monday, November 17, 2003 12:15 PM
> > To: [EMAIL PROTECTED]
> > Subject: [GENERAL] snort, acid and postgres
> >
> >
> > Ok, so here is my problem. I am running snort with ACID as
> > the query interface and FreeBSD with Postgresql 7.2 as the
> > back end database system.
> 
> What kind of hardware is the FreeBSD OS running on?  How much memory?
> What sort of disk subsystem?
> 
> > The problem I am encountering is
> > that it takes forever for acid to query the database and
> > delete alerts.
> 
> How long is "forever"?  That seems a bit vague.
> 
> > Also, there is no way to have more than one
> > person query the database without having it crawl.
> 
> There are PostgreSQL database systems with thousands of simultaneous
> users.  Perhaps you can clarify your question a bit.
> 
> > Is there
> > anyone out there that has experience tweaking postgres so
> > that it performs faster in this setup? The database is out of
> > the box with no tweaks to it.
> 
> Probably, some additional information would be helpful.
> 
> If you know the queries that you are sending, try an analyze to see what
> sort of plan is used.
> 
> Have you done any vacuum operations on your database?

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
      subscribe-nomail command to [EMAIL PROTECTED] so that your
      message can get through to the mailing list cleanly

Reply via email to