Thanks to Simon for that delete tickets script – sadly, whilst it
probably did help get rid of 6500 tickets that didn’t need to be there,
I’m still facing the same odd performance problem as earlier today.
The symptom is simple: Queries and searches are fine, but any
changes/writes to the database seem to happen quickly, but both the
command line rt tool and the web interface “stall” when waiting for the
What’s peculiar is that the changes do seem to happen fast; if I make
a comment on a ticket and click on Submit, it stalls for several moments
without updating the display – however, if I have another rt window
open and put in the ticket number that I just updated, the query returns
quickly with the changes that are still ‘Loading’ in the other window.
This is new behaviour from yesterday evening, which is why I felt it was
some sort of a size issue with the database, poor indexing, etc…as a
test I’ve built a new apache with fastcgi and am running it in parallel
(to rule out mod_perl) and I felt the delay there as well, plus, as I
say, the command line tools do the same.
An rt --create produced this timing:
Which is obviously a bit drastic. This is with rt 2-0-13, on a 1Ghz
Celeron, with 512mb of RAM. RedHat Linux 7.2, and the system is
otherwise “idle” with a very low load average, enough free memory and no
errors anywhere obvious as to disk errors (IDE, MAXTOR 6L040J2).
Total number of tickets is about 39000 or so at the moment, with the
entire rt2 database taking up about 625 megabytes in /var/lib/mysql…
If anyone has any thoughts as to why just the writing/modifications
would be producing such a noticeable delay, I’d very much like to hear
them…in the mean time, I’ll keep trying to pin this down a bit