Hi,
We’re having growing problems with tickets with a long history and lots
of comments/correspondance. When visiting certain looong tickets, RT
will take up to 2-3 minutes actually rendering the pages.
Here’s what top says about this:
PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
25455 www 1 105 0 73424K 70184K CPU1 1 1:21 58.54% perl5.8.8
796 pgsql 1 96 0 8644K 3368K select 0 67:13 10.74% postgres
Nothing in the error.log.
Of course, when I try to debug this, RT actually behaves /okay/ in
that it renders the page and doesn’t crash, but it does slow down the
server as hell. Which means that when others stumble on this ticket,
they figure the thing is stuck and hit reload repeatedly, of which you
can imagine the disastrous results…
This is:
FreeBSD lethe.koumbit.net 6.2-RELEASE-p2 FreeBSD 6.2-RELEASE-p2 #0: Fri Mar 9 14:54:27 EST 2007
RT 3.6.6 on PostgreSQL 8.2.3.
The particular ticket here has 516 transactions associated to it,
according to postgresql and around 50-60 attachments (half of which are
PGP-MIME signatures).
Never underestimate the bandwidth of a station wagon full of tapes
hurtling down the highway.
- Andrew S. Tanenbaum, “Computer Networks”
signature.asc (189 Bytes)
Welcome to the world of stateless page loads. 
The only suggestions
that I have are in two areas. Can you modify the page load to skip the
un-interesting transactions/attachments? We had to do that here with
system events (not attachments) and added a brief/full button on the
history. The default is only needed information and then if you select
“full” you get everything which may require a wait. The second area
is database monitoring. Have you identified the queries that are running?
Are they optimized? Would clustering your attachments improve retrieval
performance? Good luck.
KenOn Mon, Mar 10, 2008 at 05:58:40PM -0400, The Anarcat wrote:
Hi,
We’re having growing problems with tickets with a long history and lots
of comments/correspondance. When visiting certain looong tickets, RT
will take up to 2-3 minutes actually rendering the pages.
Here’s what top says about this:
PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
25455 www 1 105 0 73424K 70184K CPU1 1 1:21 58.54% perl5.8.8
796 pgsql 1 96 0 8644K 3368K select 0 67:13 10.74% postgres
Nothing in the error.log.
Of course, when I try to debug this, RT actually behaves /okay/ in
that it renders the page and doesn’t crash, but it does slow down the
server as hell. Which means that when others stumble on this ticket,
they figure the thing is stuck and hit reload repeatedly, of which you
can imagine the disastrous results…
This is:
FreeBSD lethe.koumbit.net 6.2-RELEASE-p2 FreeBSD 6.2-RELEASE-p2 #0: Fri Mar 9 14:54:27 EST 2007
RT 3.6.6 on PostgreSQL 8.2.3.
The particular ticket here has 516 transactions associated to it,
according to postgresql and around 50-60 attachments (half of which are
PGP-MIME signatures).
–
Never underestimate the bandwidth of a station wagon full of tapes
hurtling down the highway.
- Andrew S. Tanenbaum, “Computer Networks”
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
Welcome to the world of stateless page loads.
Whee!
The only suggestions
that I have are in two areas. Can you modify the page load to skip the
un-interesting transactions/attachments?
er… sure i’d like to!
We had to do that here with
system events (not attachments) and added a brief/full button on the
history. The default is only needed information and then if you select
“full” you get everything which may require a wait.
How did you go around doing that?
The second area
is database monitoring. Have you identified the queries that are running?
Are they optimized? Would clustering your attachments improve retrieval
performance? Good luck.
This being a production server, running tracing on the postgresql
database imposes major load, so no, I haven’t looked at the queries,
even less optimize them…
How can I go around clustering the attachments?
Thanks for the input.
A.
If builders built houses the way programmers built programs,
The first woodpecker to come along would destroy civilization.
- Gerald Weinberg
signature.asc (189 Bytes)
Welcome to the world of stateless page loads.
Whee!
The only suggestions
that I have are in two areas. Can you modify the page load to skip the
un-interesting transactions/attachments?
er… sure i’d like to!
We had to do that here with
system events (not attachments) and added a brief/full button on the
history. The default is only needed information and then if you select
“full” you get everything which may require a wait.
How did you go around doing that?
I modified Tickets/Elements/ShowHistory to skip any uninteresting
transactions and used a modification of “the show history in reverse”
documented in the wiki to add another toggle for full/brief display.
Just nixing the display of some of the attachments should help you
a lot.
The second area
is database monitoring. Have you identified the queries that are running?
Are they optimized? Would clustering your attachments improve retrieval
performance? Good luck.
This being a production server, running tracing on the postgresql
database imposes major load, so no, I haven’t looked at the queries,
even less optimize them…
I would dump the DB to a test instance, if you cannot afford the logging
of queries that take longer than 1 second or so, and run some tests on it.
How can I go around clustering the attachments?
The CLUSTER command will allow you to cluster the table around the
appropriate index. The question is which index to use. It may be
that since the attachments table is always incremented/added to that
it is basically already clustered so there would not be a substantial
change. The slow queries determined from the above testing may show
where clustering would be effective. Good luck.
Regards,
Ken