[rt-users] More performance issues with 3.0.9

[Derek Suzuki]

 One other bit of info - an strace against the perl process shows the
following call in abundance:

time(NULL)                              = 1080432262

 The expected calls to handle communication with the MySQL server are
scattered amongst a bunch of those.

-----Original Message-----
From: Derek Suzuki
To: rt-users at lists.bestpractical.com
Sent: 3/26/2004 5:20 PM
Subject: [rt-users] More performance issues with 3.0.9

	Okay, my performance problem has a bit of a history, so I'll
start
at the beginning...

	Initially, I installed RT 3.0.7 and MySQL 4.0.13 with Apache
2.0.46
and FastCGI 2.4.21 on a little box with 256MB RAM and a 500MHz P-III.
It
was never fast, but it was adequate for the two people using it.
	A few weeks ago, another group started using the system, and
usage
went up five-fold.  At first I started seeing some odd rendering
problems,
so I upgraded RT to 3.0.9.  This solved the immediate problems, but then
a
new issue arose.  Every now and then, RT would stall for 1-2 minutes at
a
time.  Additional requests would cause the perl process to peg the CPU,
and
they would eventually time out.  If the timed-out request came in
through
the mail gateway, the delivery would fail with EX_TEMPFAIL and the
message
would be redelivered later (this caused a duplicate ticket to be
created).
	Other than the high CPU usage, the system would show little sign
of
load.  The CPU would spend little time in iowait state and manual
queries to
MySQL would return quickly.  An strace against the perl process would
show
queries and results running back and forth during this time.  Eventually
everything would die down, and the server would start behaving normally.
	Earlier this week, I migrated RT to a new server with 4GB RAM,
dual
3GHz Xeons and hardware mirrored SATA drives.  The system was clearly
faster, but after the first day, we started to see those hangs happen
again.
I cranked up the memory allocation settings for InnoDB with no effect.
I
then saw a posting which suggested that MySQL 4.0.13 had a bug where
updates
on an indexed table could lock out selects for an unreasonable amount of
time.  I upgraded to 4.0.18 yesterday and everything looked good.
	Today, of course, the problem resurfaced.

	At this point I'm running out of ideas.  Does anyone have any
suggestions as to where I should be looking?

Derek
_______________________________________________
rt-users mailing list
rt-users at lists.bestpractical.com
http://lists.bestpractical.com/mailman/listinfo/rt-users

Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm