Merged Ticket Performance Degredation (still trying!)

RT Users
1

Hi all,

I posted about this problem a couple of weeks ago but unfortunately
we’re still seeing regular “hangs” and frankly I’m out of ideas. Here’s
the quick summary:

We’re using RT 3.6.1 and when loading merged tickets we see severe
performance degredation, e.g. 100 - 300 seconds per ticket. After 30
seconds, Apache gives up on the FastCGI script and generates a 500.
This problem has been documented and referenced in several posts, but I
have been unable to find a resolution. The following from Jesse seems
to be the most descriptive:

“Yep. it’s not recursion. It’s RT::Transaction::TicketObj which should
be made smarter. Rather than loading a ticket by id, it should be
loading by id and effective id. I’d love a patch.”

Here’s the full thread:
Carbon60: Cloud Consulting - Services and Solutions.

Mark Blackman suggested I update our Syslog configuration as follows (in
RT_SiteConfig.pm):

@LogToSyslogConf = ( socket => ‘native’ ) unless (@LogToSyslogConf);

I did this but unfortunately we’re seeing the same hangs. I also tried
reducing the loglevel so the merged ticket messages aren’t being stored
at all but that didn’t help either (though the log is growing much less
quickly now!).

Any suggestions would be much-appreciated.

Thanks,

Damon

P.S. I checked the code for RT 3.8.1 and the “TODO” regarding merged
ticket loads is still present so I’m assuming the performance issue is
also still present.

Damon T. Miller
Director of Application Services
Thinking Phone Networks
damon@thinkingphones.com
617-649-1388 (Office)

2

P.S. I checked the code for RT 3.8.1 and the “TODO” regarding merged
ticket loads is still present so I’m assuming the performance issue is
also still present.

according to what i see - it is not present in 5.8.1.1.
we had the same problem with 5.6.something, but then i upgraded to 5.8.1
and the problems seems to be gone - i.e. we did merge tickets and it
works.

Best regards,

depesz

Linkedin: http://www.linkedin.com/in/depesz / blog: http://www.depesz.com/
jid/gtalk: depesz@depesz.com / aim:depeszhdl / skype:depesz_hdl / gg:6749007

3

Depesz,

Thanks very much for your response. Is 5.8.1.1 publicly available? The latest official release I see on the website is 3.8.1 so I checked that code again to make sure I hadn’t missed something. I still do see the “TODO” referencing a need to modify the Load() function in Ticket_Overlay.pm at line 152. (The full path is in “lib/RT/Ticket_Overlay.pm”).

I also thought 5.8.1.1 was perhaps a development version so I checked the latest dev releases and the most recent I see is 3.8.1rc5. This preceded the official 3.8.1 release given that it was out a few days earlier (August 14th vs. August 18th for 3.8.1).

Is there a version control repository that might have the 5.8.1.1 release you mention? Or was that perhaps a typo, meaning 3.8.1? If so, it looks like the Load() function in Ticket_Overlay.pm still has an outstanding “TODO” regarding modification of the recursive search. I was trying to avoid spending the time to do an upgrade if it wasn’t likely to help, but perhaps I’ll just do it and see what happens.

There is a Perl release numbered 5.8.1, so perhaps that’s what you were referring to? Just in case that’s true, we’re running 5.8.8 (of Perl).

Thanks again,

Damon

P.S. Sorry for the duplicate email, Depesz; I forgot to CC the list. Oops!

Damon T. Miller
Director of Application Services
Thinking Phone Networks
damon@thinkingphones.com
617-649-1388 (Office)