Large # of tickets - internal server error?

RT Users
1

I was just wondering if someone could point me in the right direction of
where to look with this issue. I am running a p3-700, 1 gig of ram, FreeBSD
4.8, Apache 1.3.28+mod_ssl (from ports, also not using ssl for RT3 at this
time), mod perl 1.28 (ports), perl 5.8.0 (ports), fastcgi 2.4.0 (ports), RT
3.0.4 from ports, but recently upgraded to 3.0.5pre3. Oh, and it’s MySQL
4.0.14 also from the ports, running my-large.cnf defaults. Ok so what
happens is, I accumulated about 1200 tickets in an abuse queue from my
abuse@ email and when I go in to view them and select 50 at a time to do a
bulk delete it sits there for a while and then comes up with an internal
server error message from apache. I watch top and perl is using about 80%
cpu, mysqld will be at about 2% which sounds fine to me.

So, my question comes down to, why is perl using up so much CPU? I thought
using fastcgi would avoid mod_perl, so what exactly is using perl (fastcgi
itself?). I am far from an expert on perl, so that’s probably part of the
problem. My mod_perl, from the ports collection, is built as a module. So
I know mod_perl won’t work properly with RT, but I went with fastcgi to
avoid that problem…shouldn’t I be ok? I hope I have provided enough
details, if you need anything else let me know via the list or a private
email and I’ll get back to you ASAP. Thanks.
-Mike

2

So, my question comes down to, why is perl using up so much CPU? I thought
using fastcgi would avoid mod_perl, so what exactly is using perl (fastcgi
itself?). I am far from an expert on perl, so that’s probably part
of the

Yes. FastCGI is running perl. Perl is REQUIRED for RT.

problem. My mod_perl, from the ports collection, is built as a module. So
I know mod_perl won’t work properly with RT, but I went with fastcgi
to

mod_perl likely will work fine these days as a module. Generally,
its safe to use. If you get odd segfaults, stop using it.

3

This one time, at band camp, Mike Dydyk wrote:

So, my question comes down to, why is perl using up so much CPU? I thought
using fastcgi would avoid mod_perl, so what exactly is using perl (fastcgi
itself?). I am far from an expert on perl, so that’s probably part of the
problem. My mod_perl, from the ports collection, is built as a module. So
I know mod_perl won’t work properly with RT, but I went with fastcgi to
avoid that problem…shouldn’t I be ok? I hope I have provided enough
details, if you need anything else let me know via the list or a private
email and I’ll get back to you ASAP. Thanks.

There’s a difference between mod_perl and perl.

RT is written in the language known as perl. mod_perl is an apache module
that loads the interpreter for the language perl into the webserver itself.
mod_fastcgi is an apache module that keeps persistent copies of CGIs, thus
reducing the amount of overhead required to launch the CGI (in this case the commandline interpreter for the language perl). So, you can either run RT
“inside” the webserver with mod_perl, or you can run RT as a CGI and
connect it to the webserver using mod_fastcgi. Either way, though, you are
going to be invoking some sort of perl interpreter.

Also note: mod_perl does work properly with RT. Most people use it that
way. Only the mod_perl built for Apache 2 on Red Hat 8.0 and 9 seem to have
problems; there is nothing inherently wrong with using mod_perl on any other
operating system.

Anyway, to answer your question, we’d need to know a bit more about your
webserver, how about clagging the RT specific parts of the configuration to
the list?

You say you currently have both mod_perl and mod_fastcgi installed, so which
one are you using?

jaq@spacepants.org http://spacepants.org/jaq.gpg

4

My mod_perl, from the ports collection, is built as a module. So
I know mod_perl won’t work properly with RT
…

mod_perl likely will work fine these days as a module. Generally,
its safe to use. If you get odd segfaults, stop using it.

I went against the directions and have been running mod_perl (1.x) as a
module on freebsd 4.8 just fine with RT 3.04. We’ve had absolutely no
trouble.

I’d like to see that section of the documentation modified or removed.
[Perhaps it could be phrased as a troubleshooting hint, or at most a
warning.] Requiring people to rebuild apache just because they want to
add RT isn’t good for the acceptance level…

5

“JR” == Jim Rowan jim.rowan@starcore-dsp.com writes:

JR> I went against the directions and have been running mod_perl (1.x) as a
JR> module on freebsd 4.8 just fine with RT 3.04. We’ve had absolutely no
JR> trouble.

The only trouble you will have is if you do a (graceful) restart of
apache: you will find a massive memory leak. Workaround is to
stop/start apache rather than issuing a restart.

JR> I’d like to see that section of the documentation modified or removed.
JR> [Perhaps it could be phrased as a troubleshooting hint, or at most a
JR> warning.] Requiring people to rebuild apache just because they want to
JR> add RT isn’t good for the acceptance level…

I’ve been arguing for that for quite a while. Apparently the authors
of the documents still cling to old beliefs. :wink:

6

I didn’t know that mod_perl built as a module worked properly, all of the
documentation seemed to indicate it didn’t. I intended to be using FastCGI
and it seems to work fine. The only mod_perl stuff in my config is under
, an AddModule line for mod_perl…wouldn’t I also need a
LoadModule line for it to actually work? I didn’t care to fix it really,
because I didn’t want to use it anyways. There very well could be a problem
with my apache config, I had a hard time finding info or examples using
FastCGI and NOT using a virtualhost.

So from what you have said, RT itself is using perl…so mod_perl is not
coming in to play at all. Which leads me back to my original question, why
is perl sucking up 80% CPU and not able to maniuplate 50-100 tickets?

Apache config
<Directory “/usr/local/rt3/bin/”>
SetHandler fastcgi-script
AllowOverride AuthConfig
Options ExecCGI
Order allow,deny
Allow from all

FastCgiServer /usr/local/rt3/bin/mason_handler.fcgi

Alias /rt3 /usr/local/rt3/share/html/
<Directory “/usr/local/rt3/share/html/”>
AllowOverride AuthConfig
Options ExecCGI
Order allow,deny
Allow from all

Thanks again,
Mike-----Original Message-----
From: rt-users-admin@lists.fsck.com
[mailto:rt-users-admin@lists.fsck.com]On Behalf Of Jamie Wilkinson
Sent: Friday, August 15, 2003 2:57 AM
To: rt-users@lists.fsck.com
Subject: Re: [rt-users] Large # of tickets - internal server error?

Also note: mod_perl does work properly with RT. Most people use it that
way. Only the mod_perl built for Apache 2 on Red Hat 8.0 and 9 seem to have
problems; there is nothing inherently wrong with using mod_perl on any other
operating system.

Anyway, to answer your question, we’d need to know a bit more about your
webserver, how about clagging the RT specific parts of the configuration to
the list?

You say you currently have both mod_perl and mod_fastcgi installed, so which
one are you using?

jaq@spacepants.org http://spacepants.org/jaq.gpg
rt-users mailing list
rt-users@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users

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

7

I’d like to see that section of the documentation modified or removed.
[Perhaps it could be phrased as a troubleshooting hint, or at most a
warning.] Requiring people to rebuild apache just because they want to
add RT isn’t good for the acceptance level…

HTML::Mason, which is a hard requirement for RT’s web interface has an
equivalent notice and the developers will not support anyone with
mod_perl built as a DSO. If Mason gets rid of the requirement, we will
too.

Request Tracker... So much more than a help desk — Best Practical Solutions – Trouble Ticketing. Free.