I have RT 3.2.2 with RT/FM installed on Apache 1.3.31 with mod_perl 1.29
and MySQL 4.1.7 on FreeBSD 4.10-Stable. I’ve had problems ever since
moving (last October) to RT3 from very happy life with 2.0.15.
I think that I finally figured out part of it, which was an
/etc/newsyslog.conf config error. I made a correction earlier today
based on The FreeBSD Diary -- Apache - rotating log files.
Unfortunately, Apache's httpd processes still grow in memory usage to
very large sizes (400MB+ over two weeks) and sometimes take a very long
time (20+ minutes) to display long pages and unusual-but-tolerable
periods on short pages. For example, my ticket 3267 will never fully
load. Rendering will pause on screen before the third comment (usually
before any of the History section) and then never finishes even when the
httpd in question uses 99%+ of the CPU time. I usually end up restarting
Apache after a few hours so that the box doesn’t slow down.
I've used the RT log files, the MySQL log files, Apache log files,
upgraded MySQL, upgraded Perl, upgraded Apache, reinstalled mod_perl,
upgraded to the latest DBIx::SearchBuilder from CPAN (from 1.15 to 1.16)
and have gotten no closer to figuring this out. Upgrading the RAM to
1.5GB seems to have helped a little bit, but the main problem (not
displaying long tickets like 3267, taking too long with all tickets,
etc.) is still not solved.
Can anyone offer any tips, pointers, docs, anecdotes, or any help? I'm
getting desperate. I don’t want to replace RT, but I’m running out of
options.
Thanks in advance,
Jaime
Some parts of your experience sound similar to mine, although not quite
as bad, and it’s making me question my assumptions about whether new
hardware will get me the speed boost I need.
I was running RT 2.0.1x on a FreeBSD 4.6 on good server hardware at my
previous job and it was very responsive.
Running the 3.x series here at my new job it feels slower than I’m used
to. Short tickets (1 correspondence) takes ~3 seconds to load, Medium
tickets (20 comments/correspondence about 20 seconds, Longest Tickets
(e.g. more than 50 comments/correspondence) ~2+ minutes. My assumption
is that this is due to the desktop-class hardware I installed RT on.
I’ve tried a lot of different optimizations
(Request Tracker Wiki), with little
effect.
So I’m assuing that it’s the underpowered hardware: (dual P3-700’s 512MB
RAM 5400 RPM IDE drive)
Current Build: FreeBSD 4.11 (originally 4.8) / RT 3.2.2 / Perl 5.8.4 /
Apache 1.33 Modssl 2.8.22 / Mod_Perl
1.29 / Sendmail 8.13.1/
I’m getting a new Dell PowerEdge (P4 3.2Ghz, 4 GB Ram, 10K RPM SCSI)
soon 
.
Assuming fast networking, reasonable install (FreeBSD 4.11) can I expect
a short ticket to load in < 1 second, < 2 seconds medium tickets,
longest tickets < 10 seconds? Are people running RT on hardware in this
range finding that performance?
I’m also contemplating building this new box with FreeBSD 5.3. Have
people had a good experience with RT on FreeBSD 5.3?
Thanks,
Mike
Hi Mike,
As another data point;
So I’m assuing that it’s the underpowered hardware: (dual P3-700’s 512MB
RAM 5400 RPM IDE drive)
Current Build: FreeBSD 4.11 (originally 4.8) / RT 3.2.2 / Perl 5.8.4 /
Apache 1.33 Modssl 2.8.22 / Mod_Perl
1.29 / Sendmail 8.13.1/
We’re running RT 3.2.2 on an ancient Dell 6300 with Dual PIII 500/Xeon
processors and 2Gb of RAM under FreeBSD 4.9-RELEASE-p11. The box uses
disk attached via SCSI from one of our IBM Shark storage arrays. We are
using MySQL 4.0.16, Apache 2.0.50, mod_perl2 1.99r14 and Perl 5.8.4. I
compiled MySQL with LinuxThreads and run the “huge” mysql config (this
host also has a 196 million row web log database).
We have just under 6000 tickets and no ticket display takes more than 10
seconds. It probably has around 6 to 10 concurrent users.
The apache processes sit at around 55Mb resident and don’t seem to grow
much.
I’m getting a new Dell PowerEdge (P4 3.2Ghz, 4 GB Ram, 10K RPM SCSI)
soon .
I think the memory and faster scsi disk will help more than the faster
processor.
I’m also contemplating building this new box with FreeBSD 5.3. Have
people had a good experience with RT on FreeBSD 5.3?
No experience yet, but I’m contemplating moving to it reasonably soon as
I can’t currently backup the stupidly large weblog database to TSM and
I’d like to try MySQL with native threads rather than the heavyweight
linuxthreads.
Carl.
I would have to echo Carl Makin’s input that more memory and better
disks would provide a greater benefit than a processor increase.
So I’m assuing that it’s the underpowered hardware: (dual P3-700’s 512MB
RAM 5400 RPM IDE drive)
Current Build: FreeBSD 4.11 (originally 4.8) / RT 3.2.2 / Perl 5.8.4 /
Apache 1.33 Modssl 2.8.22 / Mod_Perl
1.29 / Sendmail 8.13.1/
I’m getting a new Dell PowerEdge (P4 3.2Ghz, 4 GB Ram, 10K RPM SCSI)
soon .
I think the memory and faster scsi disk will help more than the faster
processor.
I think that the biggest hit your are experiencing is due to the fact
that you are running on a 5400 RPM IDE drive. A 5400 RPM drive is
horrifically slow. In fact, 5400RPM drives were what used to hold back
the idea of companies adopting anything IDE based (going back about 8
years or so)… Their seek time is awful, the speed is pitiful, and the
overall performance is completely dogged. I’d personally chuck that
drive and pick up an Ultra ATA 7200RPM drive wth 8MB cache (you can get
them cheap now-a-days, especially with a rebate).
You will notice, from a user perspective, the difference between a
5400RPM drive and a 7200RPM drive.
If you did that, I think you would be pleased with the performance
difference.
Memory would help, too, but 512MB for the size of the environment you
are running on, is probably fine… it’s closer to the lower end of the
memory scale, but it should be ok. You’d see a performance boost if you
went to 786 or 1024, but not as big of a boost as you would see by
upgrading the drive.
And, finally, I have personally seen a large boost in performance by
running under mod_fastcgi with 3 or 5 instances running vs mod_perl in
the three locations that I have either installed, maintained, or (in one
instance) consulted on.
-Rich