Andreas Wahlfeldt wrote:
hi andy,
what you are going to do is EXTREMLY dangerous to the integrety of your
rt-db and as far as i know not supported in any way.
[snip]Message: 5
Date: Wed, 24 Nov 2004 18:03:31 -0800
From: Andy Moran andy@wildbrain.com
Subject: [rt-users] Deleting ‘spam’ tickets
To: rt-users@lists.bestpractical.com
Message-ID: 41A53D73.2030408@wildbrain.com
Content-Type: text/plain; charset=ISO-8859-1Hello!
We are using RT 2.0.13. Most of our tickets in our ticketing
databases are a result of spam messages generating tickets.
Fortunately, those get filtered to another queue where they await
approval so we don’t see them… However, I feel like they are slowing
down our ticketing system as there are hundreds of real tickets to
thousands of spam generated tickets.It was proposed that we manually go into our postgresql database and
remove the tickets in question. My questions: Would removing
(permanently) these tickets be possible, would it adversely effect RT
somehow that the ticket no longer exists, and would RT reuse those
ticket numbers at all?
If I may be so presumptive to offer some advice, really make sure that
your database is the slow link in the RT chain. The point of a database
is to be able to access information at any location in the database more
or less as fast as anywhere else, and to be honest, even hundreds of
thousands of items is something that postgresql should be able to handle
without blinking.
I guess my point is, don’t engage in a possibly destructive activty when
it’s very unlikely to yield any upside benefits. If you feel the system
is slow, start collecting data on what the system is doing when it feels
slow. Watch CPU, disk / network utilization. RT (more precisely
mod_perl) is a memory and CPU hog. I have a small database that runs
comfortably on a dual p3-1GHz / 570MB RAM platform. I was getting
complaints until I added the second CPU…
Graham
gdunn.vcf (296 Bytes)