Performance Issues

RT Users
41

So I’ve watched the mason_handler processes and I’m seeing lots
and lots of two things that probably don’t need to happen
as much as they do.

I don’t know if it makes a difference, but I’ve kept my fedora
core2 system completely updated with ‘yum update’ (up2date should
do the same thing), and before I started using it in production
I did a ‘perl -MCPAN -eshell’, used the ‘r’ command to see
recommended module updates, and installed anything that looked
like it might be relevant. I also dropped in DBIx-SearchBuilder-1.10
when it was announced.

Les Mikesell
les@futuresource.com

42

FastCgi has some nifty features and some ways to tweak performance.
Believe me, you will find a HUGE improvement if your FastCgiServer line
looks something like the following (specifically, the “-processes”
argument):
FastCgiServer /your_path_to_your_rt_install/bin/mason_handler.fcgi
-idle-timeout 120 -processes 5

A dual 600Mhz box isn’t the greatest, but, for RT and only RT (plus the
webserver and mysql server), that should be fine.

If, when using the above option to FastCGI, you don’t get better
performance, it’s time to start looking elsewhere (eg: on the database
side).

-Rich>On Wed, Sep 08, 2004 at 03:55:00PM -0400, Dan Pritts wrote:

I’ve got a brand-new installation of RT 3.2.1 running on Fedora
Core 1, with apache 2 & FastCGI, with a mysql backend. We have
fewer than 100 tickets in our database. In general all the tools
are those from Fedora - I think I had to build FastCGI by hand.

The hardware is a dual-CPU pentium iii 600MHz. SCSI disks and 1 gig
of RAM. Nothing else is happening on this box.

things were horribly slow with only one mason_handler.fcgi process.
(it would take 5-10 seconds to display a ticket - generally most of the

This is exactly the same as I reported 1-2 weeks ago, I run RT3.2 and
RT3 on Debian on two different machines (Celeron class w/ 768MB RAM,
idle and I normally know how to setup a server) and with only 1 ticket
and still got these 5-10 seconds with either fcgi, scgi and mod_perl on
Apache1.3. I also checked for timeouting DNS queries but with no luck.

I would really love to use RT but these numbers are of course not usable
for production use. I’m glad another user just reported <1s per ticket
which means that it is not broken by design.

So Any ideas what could cause such a delay?

thanks,

-christian-

43

Thanks for your response.

I originally started with just 1 FastCGI. I was the only user of the
system so I don’t think it was timing out waiting for that FastCGI to
become available - but it was slow as heck.

I increased it to 12 processes (based on some online docs I found) and
later, based on this list’s advice, dropped it to 4. When I dropped it
from 12 to 4 I did see a minor improvement that I attributed to caching
by the FastCGI processes, but things were still awfully slow.

Based on what I have picked up about FastCGI, I think that the goal for
tuning the number of processes running should be “enough so that there
is always one for a new user connecting, but not many more so that the
FastCGIs can cache things effectively.”

Is that an accurate portrayal of things as you understand them?
In particular, does each user session use a single FastCGI or will the
system use them in parallel to fulfill a single web hit?

I am very confident that my problem is not in the database. Simply
watching the system with “top” showed that the database was idle and
the perl mason_handler processes were eating the CPU for seconds at
a time. Changing the mysql config from the default to a config based
on my-large.cnf made no appreciable difference other than in the
amount of RAM that mysql uses.

Since I sent my original message I have thrown hardware at the problem.
I am now running with a 2.4GHz Xeon hyperthreading CPU and things are
much better, the system is now usable. I would still not consider the
performance great.On Tue, Oct 12, 2004 at 11:51:30AM -0400, Rich West wrote:

FastCgi has some nifty features and some ways to tweak performance.
Believe me, you will find a HUGE improvement if your FastCgiServer line
looks something like the following (specifically, the “-processes”
argument):
FastCgiServer /your_path_to_your_rt_install/bin/mason_handler.fcgi
-idle-timeout 120 -processes 5

A dual 600Mhz box isn’t the greatest, but, for RT and only RT (plus the
webserver and mysql server), that should be fine.

If, when using the above option to FastCGI, you don’t get better
performance, it’s time to start looking elsewhere (eg: on the database
side).

-Rich

On Wed, Sep 08, 2004 at 03:55:00PM -0400, Dan Pritts wrote:

I’ve got a brand-new installation of RT 3.2.1 running on Fedora
Core 1, with apache 2 & FastCGI, with a mysql backend. We have
fewer than 100 tickets in our database. In general all the tools
are those from Fedora - I think I had to build FastCGI by hand.

The hardware is a dual-CPU pentium iii 600MHz. SCSI disks and 1 gig
of RAM. Nothing else is happening on this box.

things were horribly slow with only one mason_handler.fcgi process.
(it would take 5-10 seconds to display a ticket - generally most of the

This is exactly the same as I reported 1-2 weeks ago, I run RT3.2 and
RT3 on Debian on two different machines (Celeron class w/ 768MB RAM,
idle and I normally know how to setup a server) and with only 1 ticket
and still got these 5-10 seconds with either fcgi, scgi and mod_perl on
Apache1.3. I also checked for timeouting DNS queries but with no luck.

I would really love to use RT but these numbers are of course not usable
for production use. I’m glad another user just reported <1s per ticket
which means that it is not broken by design.

So Any ideas what could cause such a delay?

thanks,

-christian-

danno
dan pritts - systems administrator - internet2
734/352-4953 office 734/834-7224 mobile

44

Dan Pritts wrote:

Based on what I have picked up about FastCGI, I think that the goal for
tuning the number of processes running should be “enough so that there
is always one for a new user connecting, but not many more so that the
FastCGIs can cache things effectively.”

Is that an accurate portrayal of things as you understand them?

Pretty much. You have to base it upon your system load (number of
requests), but yes. I believe a minimum is about 3 FastCGI servers,
with a generalized max being around 6 to 8 (and 8 is pushing it).

In particular, does each user session use a single FastCGI or will the
system use them in parallel to fulfill a single web hit?

Actually, each user’s request goes to a fastcgi server process. It is
similar to the way that httpd handles requests. So, if you use a
typical browser to pull up a page, it may contain a number of requests,
which get spread across the fastcgi servers.

The mozilla browser’s http-pipelining helps a bit, too. :slight_smile:

I am very confident that my problem is not in the database. Simply
watching the system with “top” showed that the database was idle and
the perl mason_handler processes were eating the CPU for seconds at
a time.

Same here… this is normal…

Changing the mysql config from the default to a config based
on my-large.cnf made no appreciable difference other than in the
amount of RAM that mysql uses.

I would be curious to see your mysql modifications for my own possible
benefit. :slight_smile:

Since I sent my original message I have thrown hardware at the problem.
I am now running with a 2.4GHz Xeon hyperthreading CPU and things are
much better, the system is now usable. I would still not consider the
performance great.

Wow… That should rocket on that thing. :slight_smile:

I’ve run it on a variety of machines (Solaris, Linux), with the current
configuration on a 1.4Ghz P3 and it is rock solid.

RequestTracker, as with any helpdesk tool that has so much
functionality, will not draw pages as quickly as if you were browsing
static web pages. You will always see a bit of latency; it will not be
instantaneous. The reality is that you will see something in the area
of 2-4 seconds per page draw, which is common place.

Hope this helps!
-Rich

45

Actually, each user’s request goes to a fastcgi server process. It is
similar to the way that httpd handles requests. So, if you use a
typical browser to pull up a page, it may contain a number of requests,
which get spread across the fastcgi servers.

I am guessing here but I imagine that the frame containing the ticket
diary is a single http request. This is where it’s so slow.

I would be curious to see your mysql modifications for my own possible
benefit. :slight_smile:

Look at the example my.cnf files that come with the mysql distribution.
On my red hat system they are:

~@basie% ls /usr/share/doc/mysql-server-3.23.58/
my-huge.cnf  my-large.cnf  my-medium.cnf  my-small.cnf

I think my-small is the default. I took my-large.cnf and tweaked
it a little so it didn’t use quite so much RAM but it still uses plenty.

Didn’t make a difference; I had fewer than 100 tickets in the DB. I’m
sure it will make a difference as my database grows.

the perl mason_handler processes were eating the CPU for seconds at
a time.

Same here… this is normal…

Just to clarify, a mason_handler would eat the CPU for several seconds at
a time FOR EACH TICKET I OPENED. I’m not just saying that these processes
ate CPU in general.

RequestTracker, as with any helpdesk tool that has so much
functionality, will not draw pages as quickly as if you were browsing
static web pages. You will always see a bit of latency; it will not be
instantaneous. The reality is that you will see something in the area
of 2-4 seconds per page draw, which is common place.

Your response is interesting - it’s all a matter of expectations, I guess.
2-4 seconds is what I get now, depending on the size of the ticket
diary. It was more like 5-10 seconds per page.

I don’t know what all mason_handler is doing, but IMO, having done some
amount of this kind of programming myself, it is awfully slow at what
it does. It just shouldn’t be taking 5 CPU seconds on a 600MHz CPU to
render a single HTML page.

that said, I’m not volunteering to dig into the RT code base & fix it
by myself, although i was hoping to provide useful feedback and testing
to others working on the problem. (this is why i haven’t said anything
about this on the list for the last several weeks).

danno
dan pritts - systems administrator - internet2
734/352-4953 office 734/834-7224 mobile

46

Actually, each user’s request goes to a fastcgi server process. It
is
similar to the way that httpd handles requests. So, if you use a
typical browser to pull up a page, it may contain a number of
requests,
which get spread across the fastcgi servers.

I am guessing here but I imagine that the frame containing the ticket
diary is a single http request. This is where it’s so slow.

I would be curious to see your mysql modifications for my own possible
benefit. :slight_smile:

Look at the example my.cnf files that come with the mysql distribution.
On my red hat system they are:

~@basie% ls /usr/share/doc/mysql-server-3.23.58/
my-huge.cnf  my-large.cnf  my-medium.cnf  my-small.cnf

I think my-small is the default. I took my-large.cnf and tweaked
it a little so it didn’t use quite so much RAM but it still uses
plenty.

Didn’t make a difference; I had fewer than 100 tickets in the DB. I’m
sure it will make a difference as my database grows.

You do know that RT flat out requires MySQL 4, right?

47

You do know that RT flat out requires MySQL 4, right?

Funny you should ask. Nobody ever responded to my note of 22 september
on this topic:

http://lists.fsck.com/pipermail/rt-users/2004-September/025936.html

in which I wrote:

So I see on the installation instructions mysql version 4.x is required.

I see on the mailing list concerns that performance will be bad
without it, but no mention of any other problems.

Do I need to worry about anything other than poor performance
when running with mysql 3.23.58? ie, database corruption?
I am running with InnoDB tables.

see, the system has been up for a while with 3.23 and i didn’t
notice until now that it was an issue…i had assumed that the
rt-check-dependencies script flag everything i needed to upgrade.

unfortunately, as it turns out, now would be a difficult time for me to
do an upgrade.

As it turns out i’m past my crunch and can devote energy to the
mysql upgrade. Anything I need to look out for?

thanks for all your advice, Jesse - and thanks for RT. I know it seems
like I have been complaining a lot, but I really appreciate the quality
of RT and the time & effort that has clearly gone into it.

danno
dan pritts - systems administrator - internet2
734/352-4953 office 734/834-7224 mobile

48

Hi Guys,

We have an RT install that is performing quite poorly. Tickets take
quite a few seconds to open, sometimes 20 or more, depending on the
number of replies/comments. Our system has 896 tickets at present.

We were running 3.0.11. I upgraded to 3.2.2 hoping I might see some
performance gains but unfortunately I didn’t.

I changed my MySQL (3.23.49) tables from MyISAM to InnoDB with no
discernible performance gain.

Applied some (Kernel shared memory, MySQL buffers) of the suggestions
from the PerformanceTuning[1] section of the WiKi, again with no
noticeable increase in performance. Upgraded DBIx::SearchBuilder to 1.11

Other pertinent stats;

Apache 1.3.31
Perl 5.8.4
Linux 2.4.7-10smp
Dual PIII 500Mhz
512MB RAM
2 reasonably fast 10,000rpm SCSI discs in RAID 1.

When a ticket is being served I can see Apache using 99% CPU time for
the duration of the serve.

I’ve done much reading of the available docs. and mailing list archives.
I’m not quite sure what I should look at next. I know this class of
problem seems to be common. I haven’t seen any definitive answers. Any
pointers would be appreciated.

  1. Request Tracker Wiki
    Cliff Flood
    Systems Administrator
    V O X P I L O T
    +353 1 209 1924
49

I had this same problem and unpgraded MySQL to 4.0 and all has been
well.

Thanks,

Kevin-----Original Message-----
From: Cliff Flood [mailto:cliff.flood@voxpilot.com]
Sent: Tuesday, October 19, 2004 9:38 AM
To: rt-users@lists.bestpractical.com
Subject: [rt-users] Performance Issues

Hi Guys,

We have an RT install that is performing quite poorly. Tickets take
quite a few seconds to open, sometimes 20 or more, depending on the
number of replies/comments. Our system has 896 tickets at present.

We were running 3.0.11. I upgraded to 3.2.2 hoping I might see some
performance gains but unfortunately I didn’t.

I changed my MySQL (3.23.49) tables from MyISAM to InnoDB with no
discernible performance gain.

Applied some (Kernel shared memory, MySQL buffers) of the suggestions
from the PerformanceTuning[1] section of the WiKi, again with no
noticeable increase in performance. Upgraded DBIx::SearchBuilder to 1.11

Other pertinent stats;

Apache 1.3.31
Perl 5.8.4
Linux 2.4.7-10smp
Dual PIII 500Mhz
512MB RAM
2 reasonably fast 10,000rpm SCSI discs in RAID 1.

When a ticket is being served I can see Apache using 99% CPU time for
the duration of the serve.

I’ve done much reading of the available docs. and mailing list archives.

I’m not quite sure what I should look at next. I know this class of
problem seems to be common. I haven’t seen any definitive answers. Any
pointers would be appreciated.

  1. Request Tracker Wiki
    Cliff Flood
    Systems Administrator
    V O X P I L O T
    +353 1 209 1924
    The rt-users Archives

Be sure to check out the RT wiki at http://wiki.bestpractical.com

50

Kevin Sonney wrote:

I had this same problem and unpgraded MySQL to 4.0 and all has been
well.

What we see when a ticket is being served is an Apache CPU spike for the
duration of the serve and a small MySQL spike just after the request is
made. This leads me to believe the poor performance is the fault of
Apache+mod_perl
Also, I would have expected the change to InnoDB tables to have given a
performance boost if a slow DB was at fault.

Can you suggest how MySQL 4 might produce better results? Does RT use
different queries with the newer MySQL?

This also leads me to another question, does anyone have any suggestions
or tips on how to debug mod_perl or on general tips for improving
mod_perl performance. I really would like to get to the bottom of this
and all help is appreciated.

-----Original Message-----
From: Cliff Flood [mailto:cliff.flood@voxpilot.com]
Sent: Tuesday, October 19, 2004 9:38 AM
To: rt-users@lists.bestpractical.com
Subject: [rt-users] Performance Issues

Hi Guys,

We have an RT install that is performing quite poorly. Tickets take
quite a few seconds to open, sometimes 20 or more, depending on the
number of replies/comments. Our system has 896 tickets at present.

We were running 3.0.11. I upgraded to 3.2.2 hoping I might see some
performance gains but unfortunately I didn’t.

I changed my MySQL (3.23.49) tables from MyISAM to InnoDB with no
discernible performance gain.

Applied some (Kernel shared memory, MySQL buffers) of the suggestions
from the PerformanceTuning[1] section of the WiKi, again with no
noticeable increase in performance. Upgraded DBIx::SearchBuilder to 1.11

Other pertinent stats;

Apache 1.3.31
Perl 5.8.4
Linux 2.4.7-10smp
Dual PIII 500Mhz
512MB RAM
2 reasonably fast 10,000rpm SCSI discs in RAID 1.

When a ticket is being served I can see Apache using 99% CPU time for
the duration of the serve.

I’ve done much reading of the available docs. and mailing list archives.

I’m not quite sure what I should look at next. I know this class of
problem seems to be common. I haven’t seen any definitive answers. Any
pointers would be appreciated.

  1. Request Tracker Wiki

Cliff Flood
Systems Administrator
V O X P I L O T
+353 1 209 1924

51

Cliff Flood cliff.flood@voxpilot.com writes:

I changed my MySQL (3.23.49) tables from MyISAM to InnoDB with no
discernible performance gain.
<-snip->

You will definitely want to upgrade your MySQL to the 4.x series
(latest seems to be 4.0.21).

Espen Wiborg espenhw@empolis.no
There are 293 ways to make change for a dollar.

52

Hey guys,
I am running a pilot installation of RT and experiencing some
performance anomalies

A bit about the environment:
RT 3.6.6 on CentOS 5, using mod_perl against Postgres 8.1. Postgres and
RT on separate boxes, and are on the same switch and subnet. Both boxes
have 1GB of RAM and Xeon 2.8Ghz processors. In addition all of the
clients in this pilot are also on the same subnet. The network is
switched 10/100.

The problem
In most respects it’s living up to it’s expectations - however I am
noticing some significant lagging. Now keep in mind this is only a
pilot, I have a total of around 100 tickets, about 1800 transactions in
this system, and only 4 web interface users. When I display one of the
tickets that has 35 transactions, it takes between 19 and 28 seconds.
That strikes me as a long time to load a single ticket, and is causing
some concern about what would happen if really loaded and under heavy
use.

What I have done thus far:
I worked through the performance tuning section on the wiki - and showed
no improvement as a result. (In reality the database modifications had
already been tweaked before RT showed up).
I have run pg_top against the database and it appears the queries are
being answered in a second or less.
In monitoring the box RT runs on, when I request some of the tickets
with more transactions, it grabs the CPU and keeps it occupied at 75-95%
utilization (showing up as system time not wait) for the duration of
loading the ticket with httpd being the process that grabs the CPU.
About 40% of available RAM isn’t being used on the RT box at present -
so I don’t think it’s related to

Thus I seek the group’s wisdom - are my expectations improper for length
of time to display a ticket? If not, where else should I be looking to
address performance?

53

Hey guys,
I am running a pilot installation of RT and experiencing some
performance anomalies

A bit about the environment:
RT 3.6.6 on CentOS 5, using mod_perl against Postgres 8.1. Postgres and
RT on separate boxes, and are on the same switch and subnet. Both boxes
have 1GB of RAM and Xeon 2.8Ghz processors. In addition all of the
clients in this pilot are also on the same subnet. The network is
switched 10/100.

The problem
In most respects it’s living up to it’s expectations - however I am
noticing some significant lagging. Now keep in mind this is only a
pilot, I have a total of around 100 tickets, about 1800 transactions in
this system, and only 4 web interface users. When I display one of the
tickets that has 35 transactions, it takes between 19 and 28 seconds.
That strikes me as a long time to load a single ticket, and is causing
some concern about what would happen if really loaded and under heavy
use.

What I have done thus far:
I worked through the performance tuning section on the wiki - and showed
no improvement as a result. (In reality the database modifications had
already been tweaked before RT showed up).
I have run pg_top against the database and it appears the queries are
being answered in a second or less.
In monitoring the box RT runs on, when I request some of the tickets
with more transactions, it grabs the CPU and keeps it occupied at 75-95%
utilization (showing up as system time not wait) for the duration of
loading the ticket with httpd being the process that grabs the CPU.
About 40% of available RAM isn’t being used on the RT box at present -
so I don’t think it’s related to

Thus I seek the group’s wisdom - are my expectations improper for length
of time to display a ticket? If not, where else should I be looking to
address performance?

The only problems that I have seen people posting concerned the display
of merged tickets – see the archives for details. If you are not doing
that, could it be some sort of permissions problem or a problem with
local mods? We have many, many more tickets/users/transactions and the
display is pretty snappy. Also one comment, if you are in a pilot and
not production, now is the time to upgrade your DB to 8.3 which has
been out for a while and will support the full-text indexing that we
intend to implement here and update the wiki with the patch/process.

Ken

54

David, what kind of disks are you using on your DB server? Generally
speaking, mod_perl is slower than FastCGI - have you tried the latter?

Next, have you tried any manual queries against your DB server to see if
that’s the source of the slowness?

For reference, I just displayed a ticket with no attachments that has 100
transactions and it displayed in 25 seconds.

James MoseleyOn Wed, Jun 18, 2008 at 10:13:40AM -0400, David Nalley wrote:

Hey guys,
I am running a pilot installation of RT and experiencing some
performance anomalies

A bit about the environment:
RT 3.6.6 on CentOS 5, using mod_perl against Postgres 8.1. Postgres and
RT on separate boxes, and are on the same switch and subnet. Both boxes
have 1GB of RAM and Xeon 2.8Ghz processors. In addition all of the
clients in this pilot are also on the same subnet. The network is
switched 10/100.

The problem
In most respects it’s living up to it’s expectations - however I am
noticing some significant lagging. Now keep in mind this is only a
pilot, I have a total of around 100 tickets, about 1800 transactions in
this system, and only 4 web interface users. When I display one of the
tickets that has 35 transactions, it takes between 19 and 28 seconds.
That strikes me as a long time to load a single ticket, and is causing
some concern about what would happen if really loaded and under heavy
use.

What I have done thus far:
I worked through the performance tuning section on the wiki - and showed
no improvement as a result. (In reality the database modifications had
already been tweaked before RT showed up).
I have run pg_top against the database and it appears the queries are
being answered in a second or less.
In monitoring the box RT runs on, when I request some of the tickets
with more transactions, it grabs the CPU and keeps it occupied at 75-95%
utilization (showing up as system time not wait) for the duration of
loading the ticket with httpd being the process that grabs the CPU.
About 40% of available RAM isn’t being used on the RT box at present -
so I don’t think it’s related to

Thus I seek the group’s wisdom - are my expectations improper for length
of time to display a ticket? If not, where else should I be looking to
address performance?

55

David,

Is your problem related with search results? We have found that if we

limit the rights to see, own, modify tickets to specific groups and not
to all privileged or global roles, we had a pretty fast response time.
Hope this helps.

Kenn
LBNLOn 6/18/2008 7:13 AM, David Nalley wrote:

Hey guys,
I am running a pilot installation of RT and experiencing some
performance anomalies

A bit about the environment:
RT 3.6.6 on CentOS 5, using mod_perl against Postgres 8.1. Postgres and
RT on separate boxes, and are on the same switch and subnet. Both boxes
have 1GB of RAM and Xeon 2.8Ghz processors. In addition all of the
clients in this pilot are also on the same subnet. The network is
switched 10/100.

The problem
In most respects it’s living up to it’s expectations - however I am
noticing some significant lagging. Now keep in mind this is only a
pilot, I have a total of around 100 tickets, about 1800 transactions in
this system, and only 4 web interface users. When I display one of the
tickets that has 35 transactions, it takes between 19 and 28 seconds.
That strikes me as a long time to load a single ticket, and is causing
some concern about what would happen if really loaded and under heavy
use.

What I have done thus far:
I worked through the performance tuning section on the wiki - and showed
no improvement as a result. (In reality the database modifications had
already been tweaked before RT showed up).
I have run pg_top against the database and it appears the queries are
being answered in a second or less.
In monitoring the box RT runs on, when I request some of the tickets
with more transactions, it grabs the CPU and keeps it occupied at 75-95%
utilization (showing up as system time not wait) for the duration of
loading the ticket with httpd being the process that grabs the CPU.
About 40% of available RAM isn’t being used on the RT box at present -
so I don’t think it’s related to

Thus I seek the group’s wisdom - are my expectations improper for length
of time to display a ticket? If not, where else should I be looking to
address performance?

The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

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

56

David, what kind of disks are you using on your DB server?

Fast disks are major requirement for any DB, but such small DB can
live in the memory. As David has different servers for DB and
front-end then network latencies most probably have bigger impact on
performance.

Generally speaking, mod_perl is slower than FastCGI - have you tried the latter?

This’s not true! We have no any good RT benchmark results proving
either this or opposite.

Next, have you tried any manual queries against your DB server to see if
that’s the source of the slowness?

Agree, any not tuned database will give you poor results.

For reference, I just displayed a ticket with no attachments that has 100
transactions and it displayed in 25 seconds.

In 3.8 we improved displaying history of tickets with many
transactions. People trying RT for a new setup are encouraged to try
RC1.

James Moseley

Hey guys,
I am running a pilot installation of RT and experiencing some
performance anomalies

A bit about the environment:
RT 3.6.6 on CentOS 5, using mod_perl against Postgres 8.1. Postgres and
RT on separate boxes, and are on the same switch and subnet. Both boxes
have 1GB of RAM and Xeon 2.8Ghz processors. In addition all of the
clients in this pilot are also on the same subnet. The network is
switched 10/100.

The problem
In most respects it’s living up to it’s expectations - however I am
noticing some significant lagging. Now keep in mind this is only a
pilot, I have a total of around 100 tickets, about 1800 transactions in
this system, and only 4 web interface users. When I display one of the
tickets that has 35 transactions, it takes between 19 and 28 seconds.
That strikes me as a long time to load a single ticket, and is causing
some concern about what would happen if really loaded and under heavy
use.

What I have done thus far:
I worked through the performance tuning section on the wiki - and showed
no improvement as a result. (In reality the database modifications had
already been tweaked before RT showed up).
I have run pg_top against the database and it appears the queries are
being answered in a second or less.
In monitoring the box RT runs on, when I request some of the tickets
with more transactions, it grabs the CPU and keeps it occupied at 75-95%
utilization (showing up as system time not wait) for the duration of
loading the ticket with httpd being the process that grabs the CPU.
About 40% of available RAM isn’t being used on the RT box at present -
so I don’t think it’s related to

Thus I seek the group’s wisdom - are my expectations improper for length
of time to display a ticket? If not, where else should I be looking to
address performance?

The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

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

Best regards, Ruslan.

57

Hey guys,
I am running a pilot installation of RT and experiencing some
performance anomalies

A bit about the environment:
RT 3.6.6 on CentOS 5, using mod_perl against Postgres 8.1. Postgres
and
RT on separate boxes, and are on the same switch and subnet. Both
boxes
have 1GB of RAM and Xeon 2.8Ghz processors. In addition all of the
clients in this pilot are also on the same subnet. The network is
switched 10/100.

There’s also the RHEL/CentOS ‘overload bug’:

https://bugzilla.redhat.com/show_bug.cgi?id=196836

Not sure how much of an impact it has on RT but perhaps compile a
vanilla 5.8.x perl on the box and see if that improves performance?

-Tom