Odd performance problem - returning from submissions

Hi,

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
result.

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:

real 2m1.148s
user 0m0.850s
sys 0m0.100s

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
further.

Thanks,

Scott

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.

Have you optimized your tables since you did the mass delete?

(darren)

Those who know that they are profound strive for clarity. Those who
would like to seem profound to the crowd strive for obscurity.
– Friedrich Nietzsche