I had this problem about a month ago. Search the archives for: Apache
Session locking taking a while
You should see some info on a possible fix.
Thanks, yes. Although, that seems like a hack of some kind. The select
lock’s go away when I changed 3006 to 1 in [1] but the page still
takes almost 90 seconds to load.
Switching from mod_perl to fastcgi didn’t affect the load time, nor
did switching mysql from the default my.cnf to huge.cnf. I’m using the
default mpm-prefork settings but increasing them doesn’t appear to
decrease the load time. I feel like something in the process isn’t
threading enough and causing a bottleneck but I’m unsure as to what’s
left. Will keep digging.
Bryan
[1] /usr/share/perl5/Apache/Session/Lock/MySQL.pm
Could you check if ShowMessageStanza from 3.8 repository [1] improves
situation? See also comments below.
I had this problem about a month ago. Search the archives for: Apache
Session locking taking a while
You should see some info on a possible fix.
Thanks, yes. Although, that seems like a hack of some kind. The select
lock’s go away when I changed 3006 to 1 in [1] but the page still
takes almost 90 seconds to load.
It’s certainly a hack that doesn’t improve performance in any way.
Switching from mod_perl to fastcgi didn’t affect the load time, nor
MP and FCGI are pretty close in speed.
did switching mysql from the default my.cnf to huge.cnf. I’m using the
default my.cnf is not an option for any DB based application.
default mpm-prefork settings but increasing them doesn’t appear to
decrease the load time. I feel like something in the process isn’t
threading enough and causing a bottleneck but I’m unsure as to what’s
left. Will keep digging.
Start from identifying where RT spends more time during the request.
Bryan
[1] http://svn.bestpractical.com/cgi-bin/index.cgi/bps/view/rt/3.8/trunk/share/html/Ticket/Elements/ShowMessageStanza
Best regards, Ruslan.
Could you check if ShowMessageStanza from 3.8 repository [1] improves
situation? See also comments below.
[1] http://svn.bestpractical.com/cgi-bin/index.cgi/bps/view/rt/3.8/trunk/share/html/Ticket/Elements/ShowMessageStanza
Installed this and restarted. Didn’t change the time to load. Pretty
stable at just under 90 seconds for this ticket.
Start from identifying where RT spends more time during the request.
Turned on ‘debug’ logging to a file. When loading this ticket I see
many lines like this:
[Mon Dec 8 23:37:12 2008] [debug]: We found a merged ticket.1721/1698
(/opt/rt3/bin/…/lib/RT/Ticket_Overlay.pm:185)
After the first line, it will pause for one second, then print three
more of the exact messages at the same time with the same timestamp as
the first. Four messages every second for the 90 seconds it took for
the ticket to load.
After seeing this I opened up a few dozen tickets and watched the
debugging log. Every ticket without merges took under two seconds,
most of them a fraction of a second (short ones). Tickets with merges
took 50-110 seconds. Definitely looks like some sort of recursive loop
to do with parsing ticket merges.
Bryan
http://rt3.fsck.com//Ticket/Display.html?id=12774On Tue, Dec 9, 2008 at 2:50 AM, Bryan McLellan btm@loftninjas.org wrote:
On Thu, Dec 4, 2008 at 6:06 PM, Ruslan Zakirov ruz@bestpractical.com wrote:
Could you check if ShowMessageStanza from 3.8 repository [1] improves
situation? See also comments below.
[1] http://svn.bestpractical.com/cgi-bin/index.cgi/bps/view/rt/3.8/trunk/share/html/Ticket/Elements/ShowMessageStanza
Installed this and restarted. Didn’t change the time to load. Pretty
stable at just under 90 seconds for this ticket.
Start from identifying where RT spends more time during the request.
Turned on ‘debug’ logging to a file. When loading this ticket I see
many lines like this:
[Mon Dec 8 23:37:12 2008] [debug]: We found a merged ticket.1721/1698
(/opt/rt3/bin/…/lib/RT/Ticket_Overlay.pm:185)
After the first line, it will pause for one second, then print three
more of the exact messages at the same time with the same timestamp as
the first. Four messages every second for the 90 seconds it took for
the ticket to load.
After seeing this I opened up a few dozen tickets and watched the
debugging log. Every ticket without merges took under two seconds,
most of them a fraction of a second (short ones). Tickets with merges
took 50-110 seconds. Definitely looks like some sort of recursive loop
to do with parsing ticket merges.
Bryan
Best regards, Ruslan.
http://rt3.fsck.com//Ticket/Display.html?id=12774
Note that to read that, login as guest/guest.
That’s it, thanks. Added this to RT_SiteConfig.pm.
Set($LogToSyslog , ‘info’);
Also linked in that bug is a debian bug [1]. They also discuss that
installing the debian package ‘libsys-syslog-perl’ should resolve this
issue.
Maybe RT_Config.pm should ship with LogToSyslog set to info as a
general measure rather than related to this bug?
Bryan
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=498692