Hi All,
We have upgraded to 3.6.6 over the weekend and also run some
optimisation against the database but performance is still very poor.
I have looked at RTx::RightMatrix and Everyone definately does not have
OwnTickets rights unless that is lying to me, which I doubt.
I've used the tuning-primer.sh script to do some tuning and performance
has improved somewhat, as query builder now only take 300 seconds
average to load instead of 400, but it is still unusable which is
frustrating the users. It's going to take another 36 hours before I can
check how the optimisation is going.
I couldn't get the MySQLTuner to run, but I'll take a look at the perl
this week if I get a chance.
If anyone else has any ideas at all, I'm open to suggestions, including
witchcraft :)
Richard
[EMAIL PROTECTED] wrote:
Today's Topics:
1. Re: RT 3.6.4 poor query performance (Jesse Vincent)
2. Re: RT 3.6.4 poor query performance (Toby Darling)
----------------------------------------------------------------------
Message: 1
Date: Thu, 13 Mar 2008 11:45:53 -0400
From: Jesse Vincent <[EMAIL PROTECTED]>
Subject: Re: [rt-users] RT 3.6.4 poor query performance
To: Richard Ellis <[EMAIL PROTECTED]>
Cc: rt-users@lists.bestpractical.com
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset="us-ascii"
On Mar 13, 2008, at 8:46 AM, Richard Ellis wrote:
Hi All,
We have recently updated our RT instance from 3.4.6 running on
Solaris 9
to a new server running Solaris 10 and 3.6.4.
You probably want RT 3.6.6 if you're on MySQL. Ruz did some serious
query optimization. But my first guess is that you've granted
"Everybody" the right to OwnTickets somewhere.
Everything works perfectly and we have removed all of the
customisations
that we used to use for a virtually vanilla 3.6.4 install. However,
when
opening the Query Builder page, performance slows to a massive extent.
Average page load is under 1 second, but performing any action in
Query
Builder averages 400 seconds.
I thought it was the database so upgraded mysql from 5.0.34 to
5.0.51a,
but that made no difference. I then upgraded DBIx::SearchBuilder to
the
latest version and DBD::mysql but it is still as bad. Even upgraded
every single perl module to latest and restarted everything, but still
as bad.
mysqlcheck rt3 says everything is ok.
There are only 10,000 tickets so it shouldn't be a volume problem.
Running on perl 5.8.8.
Anyone any ideas?
Richard
_______________________________________________
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
Community help: http://wiki.bestpractical.com
Commercial support: [EMAIL PROTECTED]
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.bestpractical.com/pipermail/rt-users/attachments/20080313/85609c29/attachment-0001.pgp
------------------------------
Message: 2
Date: Thu, 13 Mar 2008 15:53:24 +0000
From: Toby Darling <[EMAIL PROTECTED]>
Subject: Re: [rt-users] RT 3.6.4 poor query performance
To: Richard Ellis <[EMAIL PROTECTED]>, rt-users
<rt-users@lists.bestpractical.com>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hi Richard
That crashes out with a divide by zero error in the scripting, but it
looks really cool.
[--] Status: +Archive -BDB -Federated +InnoDB -ISAM -NDBCluster
[--] Data in MyISAM tables: 2M (Tables: 39)
[--] Data in InnoDB tables: 1015M (Tables: 20)
Use of uninitialized value in division (/) at ./mysqltuner.pl line 362 (#1)
Illegal division by zero at ./mysqltuner.pl line 362 (#2)
(F) You tried to divide a number by 0. Either something was wrong in
your logic, or you need to put a conditional in to guard against
meaningless input.
That indicates something went wrong earlier in getting $physical_memory
(assuming you're using v0.8.6). Any error messages or warnings at the
start?. Try chucking some print statements in the os_setup function to
see where it's going wrong.
I should point out that I've nothing to do with the MySQLTuner project,
I've not even actually run it myself, just looked at the output with the
guys that look after the mysql/database.
Cheers
Toby
--
Sun.com <http://www.sun.com> * Richard Ellis *
Technical Developer, .Sun eBusiness
*Sun Microsystems, Inc.*
Phone x(70) 24727/+44-1252-424 727
Fax +44 1252 420410
Email [EMAIL PROTECTED]
sun.com
_______________________________________________
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
Community help: http://wiki.bestpractical.com
Commercial support: [EMAIL PROTECTED]
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
