[rt-users] speeding up rt-shredder

[Mark Jenks]

Here is a crazy idea that I'm sure will have some kickback.   But you can run more than one version of RT on the same box.   Archive the old one and start a new one and learn from the lessons?

-Mark

-----Original Message-----
From: rt-users-bounces at lists.bestpractical.com [mailto:rt-users-bounces at lists.bestpractical.com] On Behalf Of ronald higgins
Sent: Tuesday, July 27, 2010 5:26 PM
To: Maxwell Rathbone
Cc: rt-users at lists.bestpractical.com
Subject: Re: [rt-users] speeding up rt-shredder

Well, @ 1 ticket deleted per 40 seconds it will only take 324 days to
clean up the DB.....

This is a bit crazy.


On Tue, Jul 27, 2010 at 10:33 PM, Maxwell Rathbone
<mrathbone at sagonet.com> wrote:
>  I'd love the ability to export the attachments and store them on the
> filesystem instead of in the database. Would certainly cut down the database
> size!
>
> I did find this, if it helps anyone:
> http://github.com/bestpractical/rt-extension-utils/blob/master/sbin/rt-extract-attachment
>
> This allows the extraction or exporting of the attachments. However that
> still doesn't solve the problem of the attachment being in the database, or
> how to reference it from the ticket.
>
> I read on this mailing list on 4/29, regarding "Attachments on disk?":
> Hi Thierry,
> there is a addon bps wrote but it is not available public at the moment.
> Hopefully Jesse will push it out some day.
>
> Torsten
>
> So as it stands, it appears there still is no method of doing this. So if
> anyone succeeds in writing a patch, please share it!
>
> Max
>
> On 7/27/2010 4:08 PM, Asif Iqbal wrote:
>>
>> On Tue, Jul 27, 2010 at 3:54 PM, G.Booth<G.Booth at lboro.ac.uk>  wrote:
>>>
>>> On Tue, 27 Jul 2010 21:28:37 +0200
>>>  ronald higgins<ronald.higgins at gmail.com>  wrote:
>>>>
>>>> Hi Garry,
>>>>
>>>> The RT DB is currently 215GB in size, 1.5 Million Tickets (Attachments
>>>> table has 7 million entries).
>>>> Yes, this badboy is what I inherited with the new job. I've already
>>>> built another MySQL DB with the tables partitioned intended for
>>>> eventual cut over
>>>> but the last few days have seen the current prod db taking a hit
>>>> performance wise which is when i really started digging through the
>>>> tickets looking for a stop gap until we can cut over, and i'm sure
>>>> cutting the Tickets down by 700 000 will make a difference.
>>>>
>>>> By all means, send it :) All tools of the trade are always gladly
>>>> received
>>>> :)
>>>
>>> OMFG!
>>> Mine is 4GB, 150000 tickets, so it looks like you've got some big
>>> attachments!
>>>
>>> Think this will be painful!
>>> will send script with explanation when I get back.
>>> I'd seriously look at the attachments table as my RT is 10% of yours in
>>> tickets, but only 2% the size.
>>>
>>> Can you zap attachments above 1Gb?
>>
>> would be nice if the attachments could be converted to link.
>> we have a ftp server in same network  that has lots of space.
>>
>> Anyone has done anything like this?
>>
>> If you reply please change the subject too.
>>
>>>
>>> regards
>>> Garry
>>>
>>> Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
>>> Buy a copy at http://rtbook.bestpractical.com
>>>
>>
>>
>
>
> Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
> Buy a copy at http://rtbook.bestpractical.com
>

Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

CONFIDENTIALITY NOTICE:  The information contained in this email message, including any attachments, may be 
privileged, confidential and otherwise protected from disclosure.  If the reader of this message is not the 
intended recipient, you are hereby notified that any use, dissemination, distribution or copying of this 
message, including any attachments, is strictly prohibited.  If you have received this email message in 
error, please notify the sender by reply email and delete/destroy the email message, including attachments, 
and any copies thereof.  Although we have taken precautions to minimize the risk of transmitting viruses via 
email and attachments thereto, we do not guarantee that either is virus-free, and we accept no liability for 
any damages sustained as a result of any such viruses.