RT 3.6 performance problems

RT Users
1

I’ve just upgraded our RT install to 3.6.1, and am having some problems with it.

I can log in ok; I see the landing page; I can edit configuration, preferences, tools, etc. But the Tickets link is the link of doom.

If I click on “Tickets”, I get the beginnings of a Query Builder page, but it just thrashes around in an endless load state for about 10 minutes (with apache chewing up >700 meg and 99% cpu), then eventually dies. I get a partial form - pull-downs for id, subject, queue, status and owner. It gets about halfway through the Owner list before dying.

We’re using MySQL 5.0.22, and we have 156,000 users in the Users table. I’m suspecting that’s the problem.

I’m curious if anyone else is successfully using RT3 for a large number of users? Is there any solution here other than deleting a bunch of users?

Thanks,

– Jackie Hamilton
kira@lightsphere.com

2

I’ve just upgraded our RT install to 3.6.1, and am having some problems with it.

I can log in ok; I see the landing page; I can edit configuration, preferences, tools, etc. But the Tickets link is the link of doom.

If I click on “Tickets”, I get the beginnings of a Query Builder page, but it just thrashes around in an endless load state for about 10 minutes (with apache chewing up >700 meg and 99% cpu), then eventually dies. I get a partial form - pull-downs for id, subject, queue, status and owner. It gets about halfway through the Owner list before dying.

We’re using MySQL 5.0.22, and we have 156,000 users in the Users table. I’m suspecting that’s the problem.

We’ve had a lot of problems with MySQL 5.0’s query optimizer. I’d
strongly consider running 4.1 in production instead.

3

I’ve just upgraded our RT install to 3.6.1, and am having some problems with it.

I can log in ok; I see the landing page; I can edit configuration, preferences, tools, etc. But the Tickets link is the link of doom.

If I click on “Tickets”, I get the beginnings of a Query Builder page, but it just thrashes around in an endless load state for about 10 minutes (with apache chewing up >700 meg and 99% cpu), then eventually dies. I get a partial form - pull-downs for id, subject, queue, status and owner. It gets about halfway through the Owner list before dying.

We’re using MySQL 5.0.22, and we have 156,000 users in the Users table. I’m suspecting that’s the problem.

We’ve had a lot of problems with MySQL 5.0’s query optimizer. I’d
strongly consider running 4.1 in production instead.

We have the same problem. In 3.0 only privileged users are returned in
the query builder, in 3.4+ all users are returned.

The problem appears not with the actual query - mysql 5 does remarkably
well for the actual query, but rather with the number of rows returned.
This chokes apache, the network and the browser.

Have a look at the apache log file to see the size of the html page
generated by RT for a hint (or view source in your browser if you have a
lot of memory).

I’m curious if anyone else is successfully using RT3 for a large number of users? Is there any solution here other than deleting a bunch of users?

Fraid not on our side as yet.

Thanks,

– Jackie Hamilton
kira@lightsphere.com

Regards
Theo

4

We have the same problem. In 3.0 only privileged users are returned in
the query builder, in 3.4+ all users are returned.

Have you granted “OwnTicket” to Everybody or Unprivileged users?

5

We have the same problem. In 3.0 only privileged users are returned in
the query builder, in 3.4+ all users are returned.

Have you granted “OwnTicket” to Everybody or Unprivileged users?

Our settings are as follows

Group Rights - System Groups - * - No Rights Granted
User Groups - * - No Rights Granted

User Rights - All Users - No Rights Granted

Global Group Rights - * - No Rights Granted (including Everyone)

Global User Rights - * - No Rights Granted

But I do not know what RT does by default when a ticket is created on
receipt of an email - ie. does it set OwnTicket even if the permissions
are set as above?

Then the next question is how does one unset OwnTicket for those users
that ‘should not’ have this?

Regards
Theo

6

We have the same problem. In 3.0 only privileged users are returned in
the query builder, in 3.4+ all users are returned.

Have you granted “OwnTicket” to Everybody or Unprivileged users?

Our settings are as follows

Group Rights - System Groups - * - No Rights Granted
User Groups - * - No Rights Granted

User Rights - All Users - No Rights Granted

Global Group Rights - * - No Rights Granted (including Everyone)

Global User Rights - * - No Rights Granted

But I do not know what RT does by default when a ticket is created on
receipt of an email - ie. does it set OwnTicket even if the permissions
are set as above?

It should not.

Then the next question is how does one unset OwnTicket for those users
that ‘should not’ have this?

Can you tell where OwnTicket is being set?

7

We have the same problem. In 3.0 only privileged users are returned in
the query builder, in 3.4+ all users are returned.

Have you granted “OwnTicket” to Everybody or Unprivileged users?

Our settings are as follows

Group Rights - System Groups - * - No Rights Granted
User Groups - * - No Rights Granted

User Rights - All Users - No Rights Granted

Global Group Rights - * - No Rights Granted (including Everyone)

Global User Rights - * - No Rights Granted

But I do not know what RT does by default when a ticket is created on
receipt of an email - ie. does it set OwnTicket even if the permissions
are set as above?

It should not.

Then the next question is how does one unset OwnTicket for those users
that ‘should not’ have this?

Can you tell where OwnTicket is being set?

Afraid not - our system running RT3.0 is pretty much default - tickets
come in mainly via email into various queues as per our setup. From
there on everything is standard…

What is interesting is that RT3.0 query builder only shows privileged
users but RT3.4+ does not select on the ‘privileged’ status.

A hint on where to start looking would be useful… as well as a hint on
how to unset OwnerTicket.

Regards
Theo

8

It should not.

Then the next question is how does one unset OwnTicket for those users
that ‘should not’ have this?

Can you tell where OwnTicket is being set?

Afraid not - our system running RT3.0 is pretty much default - tickets
come in mainly via email into various queues as per our setup. From
there on everything is standard…

What is interesting is that RT3.0 query builder only shows privileged
users but RT3.4+ does not select on the ‘privileged’ status.

Yep. That behaviour was…less correct and masked a possibly dangerous
configuration.

A hint on where to start looking would be useful… as well as a hint on
how to unset OwnerTicket.

SELECT * from ACL where RightName = ‘OwnTickets’;

or Todd’s RTx::RightsMatrix.

9

It should not.

Then the next question is how does one unset OwnTicket for those users
that ‘should not’ have this?

Can you tell where OwnTicket is being set?

Afraid not - our system running RT3.0 is pretty much default - tickets
come in mainly via email into various queues as per our setup. From
there on everything is standard…

What is interesting is that RT3.0 query builder only shows privileged
users but RT3.4+ does not select on the ‘privileged’ status.

Yep. That behaviour was…less correct and masked a possibly dangerous
configuration.

A hint on where to start looking would be useful… as well as a hint on
how to unset OwnerTicket.

SELECT * from ACL where RightName = ‘OwnTickets’;

or Todd’s RTx::RightsMatrix.

select count() from ACL where RightName = ‘OwnTickets’;
| count() |
| 0 |
1 row in set (0.00 sec)

:confused:

But that is on the live system (RT3.0) - I will also do it on the
upgrade system (RT 3.4.5) as soon as I get into the office - in an hour
or so.

And much appreciated.
Regards
Theo

10

select count(*) from ACL where RightName = ‘OwnTickets’;

I typoed “OwnTicket” not “OwnTickets”

11

select count(*) from ACL where RightName = ‘OwnTickets’;

I typoed “OwnTicket” not “OwnTickets”

Ooops

mysql> select count() from ACL where RightName = ‘OwnTicket’;
| count() |
| 16 |
1 row in set (0.00 sec)

Now I have to match this up to the users…

Regards
Theo

12

We have the same problem. In 3.0 only privileged users are returned in
the query builder, in 3.4+ all users are returned.

Have you granted “OwnTicket” to Everybody or Unprivileged users?

Our settings are as follows

Group Rights - System Groups - * - No Rights Granted
User Groups - * - No Rights Granted

User Rights - All Users - No Rights Granted

Global Group Rights - * - No Rights Granted (including Everyone)

Global User Rights - * - No Rights Granted

But I do not know what RT does by default when a ticket is created on
receipt of an email - ie. does it set OwnTicket even if the permissions
are set as above?

It should not.

Hmmm - perhaps some history would be useful

Our system was migrated from RT 2 to RT 3.0.2 which we are currently
running. The problem occurs when trying to upgrade to RT 3.4.[4-5] -
tried both.

I decided to do some testing by submitting a ticket from a non existent
user via email to our upgrade test system running 3.4.5.

I executed the following query (as derived from the mysql logs)

SELECT COUNT(DISTINCT main.Name) FROM
Users main,
Principals Principals_1,
ACL ACL_2,
CachedGroupMembers CachedGroupMembers_3
WHERE ((ACL_2.PrincipalId = CachedGroupMembers_3.GroupId))
AND ((ACL_2.PrincipalType = ‘Group’))
AND ((ACL_2.RightName = ‘OwnTicket’))
AND ((CachedGroupMembers_3.MemberId = Principals_1.id))
AND ((Principals_1.Disabled = ‘0’))
AND ((Principals_1.PrincipalType = ‘User’))
AND ((Principals_1.id != ‘1’))
AND ((main.id = Principals_1.id))
AND ((ACL_2.ObjectType = ‘RT::Queue’) OR
(ACL_2.ObjectType = ‘RT::System’));

The value returned before emailing the new ticket was 97602 and after
sending a new ticket from an arbitrary new email address it went up to
97603…

This with the permissions as above.

I then decided to do the same with RT 3.6.1 but with an empty database.
Before emailing a ticket the value returned was 1 (user Nobody), and
after emailing a ticket the value returned was still 1.

So this now raises the following question

Is it possible that somehow permissions for Everyone includes
‘OwnTicket’ but is not visible via the configuration interface?

This possibly due to an anomaly in either RT 2 or RT 3.0.2 and not
visible in the configuration interface for RT 3.0.2 and 3.4.5 ?

I haven’t loaded our dump into 3.6.1 as yet - running out of disk space
on my notepad…

Then the next question is how does one unset OwnTicket for those users
that ‘should not’ have this?

Can you tell where OwnTicket is being set?

My feeling is that somewhere there is a hidden bug.

And looking at emails from others we are not the only ones who are
experiencing the problem …

Regards
Theo

13

But I do not know what RT does by default when a ticket is created on
receipt of an email - ie. does it set OwnTicket even if the permissions
are set as above?

It should not.

Hmmm - perhaps some history would be useful

Our system was migrated from RT 2 to RT 3.0.2 which we are currently
running. The problem occurs when trying to upgrade to RT 3.4.[4-5] -
tried both.

I decided to do some testing by submitting a ticket from a non existent
user via email to our upgrade test system running 3.4.5.

I executed the following query (as derived from the mysql logs)

SELECT COUNT(DISTINCT main.Name) FROM
Users main,
Principals Principals_1,
ACL ACL_2,
CachedGroupMembers CachedGroupMembers_3
WHERE ((ACL_2.PrincipalId = CachedGroupMembers_3.GroupId))
AND ((ACL_2.PrincipalType = ‘Group’))
AND ((ACL_2.RightName = ‘OwnTicket’))
AND ((CachedGroupMembers_3.MemberId = Principals_1.id))
AND ((Principals_1.Disabled = ‘0’))
AND ((Principals_1.PrincipalType = ‘User’))
AND ((Principals_1.id != ‘1’))
AND ((main.id = Principals_1.id))
AND ((ACL_2.ObjectType = ‘RT::Queue’) OR
(ACL_2.ObjectType = ‘RT::System’));

The value returned before emailing the new ticket was 97602 and after
sending a new ticket from an arbitrary new email address it went up to
97603…

This with the permissions as above.

I then decided to do the same with RT 3.6.1 but with an empty database.
Before emailing a ticket the value returned was 1 (user Nobody), and
after emailing a ticket the value returned was still 1.

Yes. That’s saying the same thing as “the owner dropdown has too many
people in it”

So this now raises the following question

Is it possible that somehow permissions for Everyone includes
‘OwnTicket’ but is not visible via the configuration interface?

I suspect, but can’t prove, that you’re just not looking in the right
place.

Send this to the list:

SELECT * FROM ACL WHERE RightName = ‘OwnTicket’;

14

Send this to the list:

SELECT * FROM ACL WHERE RightName = ‘OwnTicket’;

Attached
Regards
Theo

x (1.85 KB)

15

Hi Theo,

i have the same problem, coming from 2.0, migrated to 3.4 and now to
3.6.1and the Owner Dropdowns showing too many people listed.

Torsten2006/8/25, Theo Kramer theo@flame.co.za:

On Thu, 2006-08-24 at 11:56 -0400, Jesse Vincent wrote:

Send this to the list:

SELECT * FROM ACL WHERE RightName = ‘OwnTicket’;

Attached

Regards
Theo

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

MFG

Torsten Brumm

http://www.torsten-brumm.de

16

Send this to the list:

SELECT * FROM ACL WHERE RightName = ‘OwnTicket’;

Attached

So again I went through my system with a toothpick and removed all
instances of groups and queues have OwnTicket. Now there is not one
entry visible where OwnTicket is set that I can see via the http
interface.

However, the result of the above query still shows entries and the
problem remains. Every new ticket from a different destination
increments the user count with OwnTicket…
Regards
Theo

x (936 Bytes)

17

Send this to the list:

SELECT * FROM ACL WHERE RightName = ‘OwnTicket’;

Next up:
SELECT * from Groups where id = 11;
SELECT * from Groups where id = 3;

18

Send this to the list:

SELECT * FROM ACL WHERE RightName = ‘OwnTicket’;

Next up:
SELECT * from Groups where id = 11;
SELECT * from Groups where id = 3;

Attached. So here it seems that Everyone has ‘OwnTicket’ for id 3 but it
is either not visible in the http interface or it eludes me…

Regards
Theo

x (964 Bytes)

19

Send this to the list:

SELECT * FROM ACL WHERE RightName = ‘OwnTicket’;

Next up:
SELECT * from Groups where id = 11;

ACL

| 123 | Group | 3 | OwnTicket | RT::Queue | 13 | 0 | 0 |

mysql> SELECT * from Groups where id = 3;
±—±-----±-----------------------------±---------------±---------±---------+
| id | Name | Description | Domain | Type | Instance |
±—±-----±-----------------------------±---------------±---------±---------+
| 3 | | Pseudogroup for internal use | SystemInternal | Everyone | 0 |
±—±-----±-----------------------------±---------------±---------±---------+

SELECT * from Groups where id = 3;

Attached. So here it seems that Everyone has ‘OwnTicket’ for id 3 but it
is either not visible in the http interface or it eludes me…

Nope. Queue 13. What’s Queue 13?

20

Apologies for the length of time in responding on this - been away for a
while.On Sat, 2006-08-26 at 09:28 -0400, Jesse Vincent wrote:

On Sat, Aug 26, 2006 at 10:57:38AM +0200, Theo Kramer wrote:

On Fri, 2006-08-25 at 11:47 -0400, Jesse Vincent wrote:

On Fri, Aug 25, 2006 at 01:56:59PM +0200, Theo Kramer wrote:

On Thu, 2006-08-24 at 11:56 -0400, Jesse Vincent wrote:

Send this to the list:

SELECT * FROM ACL WHERE RightName = ‘OwnTicket’;

Next up:
SELECT * from Groups where id = 11;

ACL

| 123 | Group | 3 | OwnTicket | RT::Queue | 13 | 0 | 0 |

mysql> SELECT * from Groups where id = 3;
±—±-----±-----------------------------±---------------±---------±---------+
| id | Name | Description | Domain | Type | Instance |
±—±-----±-----------------------------±---------------±---------±---------+
| 3 | | Pseudogroup for internal use | SystemInternal | Everyone | 0 |
±—±-----±-----------------------------±---------------±---------±---------+

SELECT * from Groups where id = 3;

Attached. So here it seems that Everyone has ‘OwnTicket’ for id 3 but it
is either not visible in the http interface or it eludes me…

Nope. Queue 13. What’s Queue 13?

select Name,Created,LastUpdated,Disabled from Queues where id = 13;

| Name | Created | LastUpdated | Disabled |
| testing | 2001-10-03 06:46:42 | 2002-03-04 10:16:24 | 1 |
1 row in set (0.00 sec)

Regards
Theo