[Fwd: Re: [rt-users] AW: Deleting 'spam' tickets (Andy Moran)]

[Graham Dunn]

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 at wildbrain.com>
>>Subject: [rt-users] Deleting 'spam' tickets
>>To: rt-users at lists.bestpractical.com
>>Message-ID: <41A53D73.2030408 at wildbrain.com>
>>Content-Type: text/plain; charset=ISO-8859-1
>>
>>
>>Hello!
>>
>>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





-------------- next part --------------
A non-text attachment was scrubbed...
Name: gdunn.vcf
Type: text/x-vcard
Size: 296 bytes
Desc: not available
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20041126/f8c622a1/attachment.vcf>