Web interface is slow

RT Users
1

Ever since upgrading to the 3.x series, I’ve had very slow performance
on the web interface for RT. Maybe I don’t notice this on the email
interface because it only makes small transactions instead of trying to
view the 17 comments in the ticket’s history. So, for all I know I’m
barking up the wrong tree.

I do know that performance is so bad that certain very long tickets do

not even load after 15 minutes.

RT 3.2.2
FreeBSD 4.10
Apache 1.3.33
mod_perl 1.29
MySQL 4.0.21
DBIx::SearchBuilder version 1.15 and 1.16 have been tried with the same
results
Almost 5000 tickets
7 users that login
email interface available over postfix 2.0

I've tried to install RT 3.2.2 on a different server (athena) and

reference the DB storage on the first server (zeus). Watching “top” on
both of these servers shows the mysqld process on zeus to be barely
used at all while an httpd process on athena consumes all available CPU
time for well over a half hour (and still going, so I don’t know how
long it will take) and a lot of memory (151MB and still climbing).
This ticket displayed fine in RT version 2.0.15.

The migration from 2.0.15 to 3.2.2 involved an upgrade to 3.0, use of

the migration tools, and then another upgrade to 3.2. Since this
effects the DB storage and not the web GUI, I’m not sure if this is
relevant. The use of the FreeBSD ports collections was attempted, but
manual installation from source was found to work better. Its been a
few months since I’ve done this, so please forgive me for forgetting
how it worked better. I think that it just didn’t vs. did work, but
I am not completely certain.

The command line interface appears to want a password but none that I

try work. My shell username is the same as my RT username, but that
password and the DB user password do not work. I’m not sure if this is
related.

Are there any tips that anyone can offer?

						Thanks in advance,
						Jaime

Network Administrator
Cairo-Durham Central School District
http://cns.cairodurham.org

2

RT 3.2.2
FreeBSD 4.10
Apache 1.3.33
mod_perl 1.29
MySQL 4.0.21
DBIx::SearchBuilder version 1.15 and 1.16 have been tried with the same
results
Almost 5000 tickets
7 users that login
email interface available over postfix 2.0

hi
we have no bsd here (sorry) - RT 3.09 runs on redhat 9 here
data-storage: mysql-max-4.1.8
apache 2.0.40, fastcgi

multiple fastcgi processes imho help similar to:
FastCgiServer /opt/knet_rt3/bin/mason_handler.fcgi -idle-timeout 3600
-processes 5

(without the line-break)

everything works really fine - the only catch was that we experienced similar
real delays after going from rt-2.0 to 3.0 - there was no easy solution, until
we did the following: upgraded mysql from 4.0 to 4.1
and try “r” in cpan (perl -MCPAN -e shell then enter “r” only )
you get the recommended upgrades and we did all upgrades that did not involve
getting a newer perl.

the my.cnf is pretty straigt - only added “max_allowed_packet = 32M” in [mysqld]

and somehow tried to optimize in [mysqld] for rt:

rt:

innodb_log_files_in_group=3
innodb_mirrored_log_groups=1
innodb_log_file_size=5M
innodb_log_buffer_size=8M
innodb_flush_log_at_trx_commit=1
innodb_log_archive=0
innodb_buffer_pool_size=16M
innodb_additional_mem_pool_size=2M
innodb_file_io_threads=4
innodb_lock_wait_timeout=50
sort_buffer=2M
delay_key_write=OFF
flush

actually I think most optimizations came from newerl perl-modules, but that was
done after we upgraded mysql and tried to optimize it :slight_smile:
[btw. the delay_key_write=OFF and flush helped stop mysqld-4.1.7 from occasional
crashing when working with intense rt-searches]

on the other hand we tried to upgrade to RT3.2.x already - almost always we ran
into trouble when we migrated the database using the different
upgrade-database-scripts, something we did always wrong…

hth
hk

3

Hello, Jaime. AFAI understand you have problem only with tickets that
was imported from old system. 151MB memory usage is very big for 17
transactions. Could you turn on DB query log and send it. I expect some
loop in it.

		Best regards. Ruslan.

PS: May be this ticket has a lot of file attachments…

Jaime Kikpole wrote:

4

Hello, Jaime. AFAI understand you have problem only with tickets that
was imported from old system. 151MB memory usage is very big for 17
transactions. Could you turn on DB query log and send it. I expect
some loop in it.

As far as I can tell, its *not* just the tickets that were imported.

For example, ticket 4595 is our ticket which covers this very issue,
which of course had to have been made after the import. It is getting
kind of long and may take between one and three minutes to load. It
has no file attachments, but it does have a number of entries (i.e.
comments and correspondence).

I'll RTFM and try to turn on the DB query log.  (Although tips in the

right direction would be cool. :wink: ) Then I’ll send it to the list if I
can’t figure things out for myself.

						Thanks!
						Jaime
5

Hello, Jaime. AFAI understand you have problem only with tickets that
was imported from old system. 151MB memory usage is very big for 17
transactions. Could you turn on DB query log and send it. I expect some
loop in it.

PS: May be this ticket has a lot of file attachments…

Attached is a section of my MySQL logs.  It covers (to the best of

my understanding of how the log works) the queries involved in displaying
my RT install’s ticket #1. This is a reasonably short ticket with several
entries and no attachments. This was an imported ticket that was created
in version 2.0.6, to the best of my memory.

I also noticed that my rt.log file only shows logins even though I

have the following configs:
Set($LogToFileNamed , “rt.log”);
Set($LogToFile , “debug”);

Also, the apache access logs only show the access after the web

browser finishes loading the page.

What do you think?  If there are other logs that could be handy,

please let me know.

						Jaime Kikpole

Network Administrator
Cairo-Durham Central School District
http://cns.cairodurham.org

query31.txt.gz (1.49 KB)

6

Jaime Kikpole wrote:

Hello, Jaime. AFAI understand you have problem only with tickets that
was imported from old system. 151MB memory usage is very big for 17
transactions. Could you turn on DB query log and send it. I expect some
loop in it.

PS: May be this ticket has a lot of file attachments…

Attached is a section of my MySQL logs. It covers (to the best of
my understanding of how the log works) the queries involved in displaying
my RT install’s ticket #1. This is a reasonably short ticket with several
entries and no attachments. This was an imported ticket that was created
in version 2.0.6, to the best of my memory.

I also noticed that my rt.log file only shows logins even though I
have the following configs:
Set($LogToFileNamed , “rt.log”);
Set($LogToFile , “debug”);

Also, the apache access logs only show the access after the web
browser finishes loading the page.

What do you think? If there are other logs that could be handy,
please let me know.
Log looks fine, no loops, no useless queries.
You can use mysql slow queries logs to be sure that it’s not lack of
indexes in DB or DB missconfigure. See http://wiki.bestpractical.com/?Debug.

Try 3.2.3rc1 to be sure that it’s not a bug in 3.2.2 that has been fixed.