Re: [rt-users] Adding a predefined search field
Hi I use the smart keywords feature of firefox http://support.mozilla.com/en-US/kb/Smart%20keywordswhich allows me to type rtcompany yoyodine in the LOcation bar of firefox and returns me the result of a search on a Custom Field * Go to Organize bookmarks (Show all bookmarks in FF4) * In the right-button menu, click on New bookmark * In the dialog box, add the following o Name: Search RT Company o Location: https://rt/Search/Results.html?Order=ASCOrderBy=idQuery=(Status%3D'new'OR%20Status%3D'open')AND%20'CF.%7BCompany%7D'%20LIKE%20'%s' o Keyword: rtcompany The important part is the '%s' at the end of the location. Firefox will replace it with what you type after the keyword. The location URL can be much complicated than the above. You can also add the Format (ie the Columns displayed). I usually build a search using the Search builder and copy/paste the URL. As far as I know, the smart keywords allows you only one variable (%s) Gerard On 2011-05-20 16:22, Francis L Fabrizio wrote: There’s a particular search we do constantly against our custom field “PO Number”. Since the custom field is only applied to certain queues, building the search is a two-step process of first adding the “Queue is XYZ” search term which then gives us visibility to add the PO Number search term. It’s not uncommon to need to do 20 or 30 such searches in rapid succession. This gets tedious because you have to Edit Search, delete the old value, add the new value, and repeat 30 times. What I’d really like is a search field in the upper bar (separate from the existing one) which automatically does a “search queue XYZ for tickets with PO Number value of whatever is input in the field” search. That would avoid all of these tedious steps. What’s the best way to go about adding such functionality to our RT 3.8 interface? -- Fran Fabrizio Director of Information Systems UAB College of Arts and Sciences http://www.uab.edu/cas/ http://www.uab..edu/cas/ HHB510E | 205.996.5698 | fabri...@uab.edu mailto:fabri...@uab.edu
Re: [rt-users] Please help - rt4 slow after upgrade
Seems after watching a few days this is still an issue. It seems completely
random.. some pages just... take awhile to load for some reason. 15 - 20
seconds, and then you can blast through a few pages instantly it seems...
completely random. I've checked the logs, no errors or anything that stands
out. Some of the pages that slow down don't access replying via email, so
SMTP wouldn't be the issue. I examined again my slow query logs for mysql
and yesterday got this:
# Time: 110523 2:30:10
# User@Host: rt_user[rt_user] @ localhost []
# Query_time: 6 Lock_time: 0 Rows_sent: 70390 Rows_examined: 70390
use rt3;
SELECT /*!40001 SQL_NO_CACHE */ * FROM `Attachments`;
# Time: 110523 2:30:17
# User@Host: rt_user[rt_user] @ localhost []
# Query_time: 4 Lock_time: 0 Rows_sent: 125353 Rows_examined: 125353
SELECT /*!40001 SQL_NO_CACHE */ * FROM `Transactions`;
# Time: 110523 2:30:20
# User@Host: rt_user[rt_user] @ localhost []
# Query_time: 3 Lock_time: 0 Rows_sent: 10343 Rows_examined: 10343
SELECT /*!40001 SQL_NO_CACHE */ * FROM `sessions`;
However, that's only 3 entries.. it happens much more often than that. I'm
thinking I'll see the CPU peg out maybe 5 - 8 times in a 5 min span, for
about 10 - 15 seconds each time watching top. My only thought is there's
some type of a miscommunication between apache and mysql, but I have no idea
what. At this point, I'm open to any and all suggestions. Please, if
anybody has any suggestions on where to look, I'd appreciate it.
On Thu, May 19, 2011 at 10:33 AM, Chris Hall hir...@gmail.com wrote:
Well, resolved the below a bit by adding to RT_SiteConfig.pm:
Set($WebSessionClass, Apache::Session::File);
However, CPU usage still peaks out on apache2 processes, although it
appears to be not AS frequent. Anybody have any other suggestions on areas
to look into? Some are saying the slowdown seems to occur most frequently
when updating tickets.
On Wed, May 18, 2011 at 8:36 PM, Chris Hall hir...@gmail.com wrote:
I actually saw something about that in a message to the mailing list, and
already turned it off as well, as a precaution. After searching around
some and trying out some tests, it seems the delay happens after the GET
request to the apache server, and watching the logs, nothing appears in the
log until about 20 seconds after the request to say the user asked for it..
so there's about 20 - 30 seconds of dead time from the GET to when the log
shows a request was made. On a forum recommendation, I enabled slow mysql
logging and noticed several entries in the log. Here is a sample:
# User@Host: rt_user[rt_user] @ localhost []
# Query_time: 3246 Lock_time: 0 Rows_sent: 1 Rows_examined: 0
SELECT GET_LOCK('Apache-Session-8a63b00ecb1829c65682fc75db1c05be', 3600);
# User@Host: rt_user[rt_user] @ localhost []
# Query_time: 3204 Lock_time: 0 Rows_sent: 1 Rows_examined: 0
SELECT GET_LOCK('Apache-Session-8a63b00ecb1829c65682fc75db1c05be', 3600);
# User@Host: rt_user[rt_user] @ localhost []
# Query_time: 2897 Lock_time: 0 Rows_sent: 1 Rows_examined: 0
SELECT GET_LOCK('Apache-Session-8a63b00ecb1829c65682fc75db1c05be', 3600);
# User@Host: rt_user[rt_user] @ localhost []
# Query_time: 2885 Lock_time: 0 Rows_sent: 1 Rows_examined: 0
SELECT GET_LOCK('Apache-Session-8a63b00ecb1829c65682fc75db1c05be', 3600);
# Time: 110518 19:51:37
# User@Host: rt_user[rt_user] @ localhost []
# Query_time: 1660 Lock_time: 0 Rows_sent: 1 Rows_examined: 0
SELECT GET_LOCK('Apache-Session-8a63b00ecb1829c65682fc75db1c05be', 3600);
# Time: 110518 19:56:44
# User@Host: rt_user[rt_user] @ localhost []
# Query_time: 14 Lock_time: 0 Rows_sent: 1 Rows_examined: 0
SELECT GET_LOCK('Apache-Session-29fd7421a2e8981d99740258bbb9aea3', 3600);
Dunno if they are of any help, but to me, it seems to indicate several
SELECT queries that are running long for... whatever reason. Do these logs
make sense to anybody?
On Wed, May 18, 2011 at 6:33 PM, Jonah Hirsch jw...@nau.edu wrote:
I was having this issue, same exact versions and problems with apache2. I
turned off mod_deflate and that helped a bit, but I'm still getting some
slowdowns, just not as much as before.
---
Jonah Hirsch
On Wed, May 18, 2011 at 11:31 AM, Chris Hall hir...@gmail.com wrote:
Not sure where to start here, but trying to diagnose why after an
upgrade from 3.8.8 to 4.0.0 things have slowed down tremendously. Doing
even pedestrian tasks such as loading the home screen or opening the ticket
search will about 30% of the time decide it wants to max out the cpu with
the apache2 process for roughly 20 - 30 seconds. Sometimes, loading things
happens almost instantaneously. Other times, there's this weird delay.
Not
sure where to start looking, are there any known issues that I might need
to
be aware of?
[rt-users] Fulltext search in RT4
Hi all, Have upgraded to RT4 (from 3.8.4) and I have to say it went really well, so much so that the beta became the final in one hit. Well done all at Best Practical. Only thing that does not seem to work any more is searching for tickets by looking for words in the body of messages. In 3.8 we used fulltext:word to search. This returns nothing in RT4. Is there anything equivalent, or have I missed something? Also, any idea when documentation on the new lifecycle features will appear? This was the big draw for us with RT4. Thanks, Gary
Re: [rt-users] Fulltext search in RT4
On Mon, 2011-05-23 at 14:45 +0100, Gary Holmes wrote: Only thing that does not seem to work any more is searching for tickets by looking for words in the body of messages. In 3.8 we used fulltext:word to search. This returns nothing in RT4. Is there anything equivalent, or have I missed something? As Emmanuel notes, you need to: Set( %FullTextSearch, Enable = 1 ); ...to enable the 3.8 unindexed FTS functionality. This became disabled by default in 4.0 because of the performance implications of the search on most large deployments. If you want indexed FTS, we suggest you wait for 4.0.1, as it contains a number of critical bugfixes and documentation updates in this codepath. - Alex
Re: [rt-users] Fulltext search in RT4
Alex, Emmanuel: Thanks for the heads up. Is working again, will wait for 4.0.1 for the indexed version (we've about 2000 tickets so it isn't too painful right now without it). Regards, Gary On 23 May 2011 15:11, Alex Vandiver ale...@bestpractical.com wrote: On Mon, 2011-05-23 at 14:45 +0100, Gary Holmes wrote: Only thing that does not seem to work any more is searching for tickets by looking for words in the body of messages. In 3.8 we used fulltext:word to search. This returns nothing in RT4. Is there anything equivalent, or have I missed something? As Emmanuel notes, you need to: Set( %FullTextSearch, Enable = 1 ); ...to enable the 3.8 unindexed FTS functionality. This became disabled by default in 4.0 because of the performance implications of the search on most large deployments. If you want indexed FTS, we suggest you wait for 4.0.1, as it contains a number of critical bugfixes and documentation updates in this codepath. - Alex
[rt-users] Error with ModifyUsers.html after upgrade from 3.8.7 to 4.0.0
Hi,
At UMBC, we recently upgraded our development RT instance from 3.8.7 to
4.0.0. The upgrade went smoothly, but now when we open any ticket and
click on the People tab, we are getting the following error:
System error
error: Can't use an undefined value as an ARRAY reference at
/local/rt4/share/html/Ticket/ModifyPeople.html line 115, GEN752 line 12.
context:
...
111:for my $type (qw(To Cc Bcc)) {
112:$recips{$_-address} = 1 for $scrip-ActionObj-Action-$type();
113:}
114:}
115:for my $rule (map {@{$_-Rules}} @txns) {
116:next unless $rule-{hints} $rule-{hints}{class} eq SendEmail;
117:for my $type (qw(To Cc Bcc)) {
118:$recips{$_} = 1 for @{$rule-{hints}{recips}{$type}};
119:}
...
code stack: /local/rt4/share/html/Ticket/ModifyPeople.html:115
/local/rt4/sbin/../lib/RT/Interface/Web.pm:522
/local/rt4/sbin/../lib/RT/Interface/Web.pm:271
/local/rt4/share/html/autohandler:53
It appears that this is because 'Rules' is undefined for one or more of
the transactions in the @txns array, and the map statement is attempting
to dereference an undefined value. To confirm, I tried replacing line
115 with:
for my $rule (map {@{$_-Rules}} grep(($_-Rules != undef), @txns)) {
This fixed the error, and the result is a modify people page that
appears correct at first glance. However, it's obviously a band-aid,
and not really knowing anything about RT internals, I'm worried that we
have a deeper systemic issue that's going to crop up elsewhere. Any
ideas what would cause 'Rules' to be undefined in one or more of the
transactions here? It's obviously not supposed to be undefined, or
presumably the code would already check for it.
Thanks for any insight!
Paul Riddle
Re: [rt-users] Error with ModifyUsers.html after upgrade from 3.8.7 to 4.0.0
On Mon, May 23, 2011 at 11:33:34AM -0400, Paul Riddle wrote: Hi, At UMBC, we recently upgraded our development RT instance from 3.8.7 to 4.0.0. The upgrade went smoothly, but now when we open any ticket and click on the People tab, we are getting the following error: Paul, Thanks for the report. This isn't something I've seen before. Did you install RT4 on top of your RT3 instance? At a first guess, this could be mixing code from an RT3 customization or extension. -Jesse
Re: [rt-users] Please help - rt4 slow after upgrade
On Mon, May 23, 2011 at 09:09:08AM -0400, Chris Hall wrote:
Seems after watching a few days this is still an issue. It seems completely
random.. some pages just... take awhile to load for some reason. 15 - 20
seconds, and then you can blast through a few pages instantly it seems...
completely random. I've checked the logs, no errors or anything that stands
out. Some of the pages that slow down don't access replying via email, so
SMTP wouldn't be the issue. I examined again my slow query logs for mysql
and yesterday got this:
None of these queries look like something generated by RT. RT's ORM
has some... signatures it leaves on the query.
Are you perhaps using some sort of backup or indexing tool, or an
extension developed in-house?
# Time: 110523 2:30:10
# User@Host: rt_user[rt_user] @ localhost []
# Query_time: 6 Lock_time: 0 Rows_sent: 70390 Rows_examined: 70390
use rt3;
SELECT /*!40001 SQL_NO_CACHE */ * FROM `Attachments`;
# Time: 110523 2:30:17
# User@Host: rt_user[rt_user] @ localhost []
# Query_time: 4 Lock_time: 0 Rows_sent: 125353 Rows_examined: 125353
SELECT /*!40001 SQL_NO_CACHE */ * FROM `Transactions`;
# Time: 110523 2:30:20
# User@Host: rt_user[rt_user] @ localhost []
# Query_time: 3 Lock_time: 0 Rows_sent: 10343 Rows_examined: 10343
SELECT /*!40001 SQL_NO_CACHE */ * FROM `sessions`;
If you'd like to try and examine SQL problems on a particular page, you
can enable $StatementLog and examine the output from the Configuration
- Tools page as a superuser.
-kevin
However, that's only 3 entries.. it happens much more often than that. I'm
thinking I'll see the CPU peg out maybe 5 - 8 times in a 5 min span, for
about 10 - 15 seconds each time watching top. My only thought is there's
some type of a miscommunication between apache and mysql, but I have no idea
what. At this point, I'm open to any and all suggestions. Please, if
anybody has any suggestions on where to look, I'd appreciate it.
On Thu, May 19, 2011 at 10:33 AM, Chris Hall hir...@gmail.com wrote:
Well, resolved the below a bit by adding to RT_SiteConfig.pm:
Set($WebSessionClass, Apache::Session::File);
However, CPU usage still peaks out on apache2 processes, although it
appears to be not AS frequent. Anybody have any other suggestions on areas
to look into? Some are saying the slowdown seems to occur most frequently
when updating tickets.
On Wed, May 18, 2011 at 8:36 PM, Chris Hall hir...@gmail.com wrote:
I actually saw something about that in a message to the mailing list, and
already turned it off as well, as a precaution. After searching around
some and trying out some tests, it seems the delay happens after the GET
request to the apache server, and watching the logs, nothing appears in the
log until about 20 seconds after the request to say the user asked for it..
so there's about 20 - 30 seconds of dead time from the GET to when the log
shows a request was made. On a forum recommendation, I enabled slow mysql
logging and noticed several entries in the log. Here is a sample:
# User@Host: rt_user[rt_user] @ localhost []
# Query_time: 3246 Lock_time: 0 Rows_sent: 1 Rows_examined: 0
SELECT GET_LOCK('Apache-Session-8a63b00ecb1829c65682fc75db1c05be', 3600);
# User@Host: rt_user[rt_user] @ localhost []
# Query_time: 3204 Lock_time: 0 Rows_sent: 1 Rows_examined: 0
SELECT GET_LOCK('Apache-Session-8a63b00ecb1829c65682fc75db1c05be', 3600);
# User@Host: rt_user[rt_user] @ localhost []
# Query_time: 2897 Lock_time: 0 Rows_sent: 1 Rows_examined: 0
SELECT GET_LOCK('Apache-Session-8a63b00ecb1829c65682fc75db1c05be', 3600);
# User@Host: rt_user[rt_user] @ localhost []
# Query_time: 2885 Lock_time: 0 Rows_sent: 1 Rows_examined: 0
SELECT GET_LOCK('Apache-Session-8a63b00ecb1829c65682fc75db1c05be', 3600);
# Time: 110518 19:51:37
# User@Host: rt_user[rt_user] @ localhost []
# Query_time: 1660 Lock_time: 0 Rows_sent: 1 Rows_examined: 0
SELECT GET_LOCK('Apache-Session-8a63b00ecb1829c65682fc75db1c05be', 3600);
# Time: 110518 19:56:44
# User@Host: rt_user[rt_user] @ localhost []
# Query_time: 14 Lock_time: 0 Rows_sent: 1 Rows_examined: 0
SELECT GET_LOCK('Apache-Session-29fd7421a2e8981d99740258bbb9aea3', 3600);
Dunno if they are of any help, but to me, it seems to indicate several
SELECT queries that are running long for... whatever reason. Do these logs
make sense to anybody?
On Wed, May 18, 2011 at 6:33 PM, Jonah Hirsch jw...@nau.edu wrote:
I was having this issue, same exact versions and problems with apache2. I
turned off mod_deflate and that helped a bit, but I'm still getting some
slowdowns, just not as much as before.
---
Jonah Hirsch
On Wed, May 18, 2011 at 11:31 AM, Chris Hall hir...@gmail.com wrote:
Not sure where to start here, but trying to diagnose why after an
upgrade from 3.8.8 to 4.0.0 things have slowed down
Re: [rt-users] Please help - rt4 slow after upgrade
That -really- seemed to slow down.. almost everything I did. Although when
I looked at the results, I was seeing not alot of time spent on the queries.
/index.html - 0.0208s Toggle 45 queries
/Ticket/Display.html - 0.1104s Toggle 65 queries
/Search/Results.html - 0.5969s Toggle 232 queries
The only extension I'm running is one called BriefHistory, which filters out
a lot of stuff we don't want to sift through in the comments section of
tickets, but considering the slowdown can occur on the main page, search
pages (before criteria is even entered), etc... I don't think that's the
factor. Just to be sure, I restarted without it loaded, and saw similar
delays. Below is my current RT_SiteConfig.pm.. does anything look wrong?
### Set to try to stop the lag
Set($WebSessionClass, Apache::Session::File);
Set( $rtname, '-CENSORED-');
Set($Organization , -CENSORED-);
Set($CorrespondAddress , '-CENSORED-');
Set($CommentAddress , '-CENSORED-');
Set($MailCommand, 'smtp');
Set($SMTPServer, '-CENSORED-');
Set($SMTPFrom , '-CENSORED-');
Set($NotifyActor , '1');
Set($OwnerEmail , 'root');
Set($MaxAttachmentSize , 1000);
Set($DatabaseType, 'mysql');
Set($DatabaseUser , 'rt_user'); Set($DatabasePassword , '-CENSORED-');
Set($DatabaseName , 'rt4');
Set($WebPath , );
Set($WebBaseURL , http://-CENSORED-;);
Set(@Plugins,qw(RT::Extension::BriefHistory));
1;
On Mon, May 23, 2011 at 1:42 PM, Kevin Falcone falc...@bestpractical.comwrote:
On Mon, May 23, 2011 at 09:09:08AM -0400, Chris Hall wrote:
Seems after watching a few days this is still an issue. It seems
completely
random.. some pages just... take awhile to load for some reason. 15 - 20
seconds, and then you can blast through a few pages instantly it seems...
completely random. I've checked the logs, no errors or anything that
stands
out. Some of the pages that slow down don't access replying via email,
so
SMTP wouldn't be the issue. I examined again my slow query logs for
mysql
and yesterday got this:
None of these queries look like something generated by RT. RT's ORM
has some... signatures it leaves on the query.
Are you perhaps using some sort of backup or indexing tool, or an
extension developed in-house?
# Time: 110523 2:30:10
# User@Host: rt_user[rt_user] @ localhost []
# Query_time: 6 Lock_time: 0 Rows_sent: 70390 Rows_examined: 70390
use rt3;
SELECT /*!40001 SQL_NO_CACHE */ * FROM `Attachments`;
# Time: 110523 2:30:17
# User@Host: rt_user[rt_user] @ localhost []
# Query_time: 4 Lock_time: 0 Rows_sent: 125353 Rows_examined: 125353
SELECT /*!40001 SQL_NO_CACHE */ * FROM `Transactions`;
# Time: 110523 2:30:20
# User@Host: rt_user[rt_user] @ localhost []
# Query_time: 3 Lock_time: 0 Rows_sent: 10343 Rows_examined: 10343
SELECT /*!40001 SQL_NO_CACHE */ * FROM `sessions`;
If you'd like to try and examine SQL problems on a particular page, you
can enable $StatementLog and examine the output from the Configuration
- Tools page as a superuser.
-kevin
However, that's only 3 entries.. it happens much more often than that.
I'm
thinking I'll see the CPU peg out maybe 5 - 8 times in a 5 min span, for
about 10 - 15 seconds each time watching top. My only thought is there's
some type of a miscommunication between apache and mysql, but I have no
idea
what. At this point, I'm open to any and all suggestions. Please, if
anybody has any suggestions on where to look, I'd appreciate it.
On Thu, May 19, 2011 at 10:33 AM, Chris Hall hir...@gmail.com wrote:
Well, resolved the below a bit by adding to RT_SiteConfig.pm:
Set($WebSessionClass, Apache::Session::File);
However, CPU usage still peaks out on apache2 processes, although it
appears to be not AS frequent. Anybody have any other suggestions on
areas
to look into? Some are saying the slowdown seems to occur most
frequently
when updating tickets.
On Wed, May 18, 2011 at 8:36 PM, Chris Hall hir...@gmail.com wrote:
I actually saw something about that in a message to the mailing list,
and
already turned it off as well, as a precaution. After searching
around
some and trying out some tests, it seems the delay happens after the
GET
request to the apache server, and watching the logs, nothing appears
in the
log until about 20 seconds after the request to say the user asked for
it..
so there's about 20 - 30 seconds of dead time from the GET to when the
log
shows a request was made. On a forum recommendation, I enabled slow
mysql
logging and noticed several entries in the log. Here is a sample:
# User@Host: rt_user[rt_user] @ localhost []
# Query_time: 3246 Lock_time: 0 Rows_sent: 1 Rows_examined: 0
SELECT GET_LOCK('Apache-Session-8a63b00ecb1829c65682fc75db1c05be',
3600);
# User@Host: rt_user[rt_user] @ localhost []
# Query_time: 3204 Lock_time: 0 Rows_sent: 1 Rows_examined: 0
SELECT
Re: [rt-users] Please help - rt4 slow after upgrade
On Mon, May 23, 2011 at 02:23:26PM -0400, Chris Hall wrote: That -really- seemed to slow down.. almost everything I did. Although when I looked at the results, I was seeing not alot of time spent on the queries. /index.html - 0.0208s Toggle 45 queries /Ticket/Display.html - 0.1104s Toggle 65 queries /Search/Results.html - 0.5969s Toggle 232 queries Logging all the queries is going to add some load, but it doesn't appear that this is the RT frontend based on your findings. I'd concentrate on finding out what software is issuing those full stable scans. -kevin The only extension I'm running is one called BriefHistory, which filters out a lot of stuff we don't want to sift through in the comments section of tickets, but considering the slowdown can occur on the main page, search pages (before criteria is even entered), etc... I don't think that's the factor. Just to be sure, I restarted without it loaded, and saw similar delays. Below is my current RT_SiteConfig.pm.. does anything look wrong? ### Set to try to stop the lag Set($WebSessionClass, Apache::Session::File); Set( $rtname, '-CENSORED-'); Set($Organization , -CENSORED-); Set($CorrespondAddress , '-CENSORED-'); Set($CommentAddress , '-CENSORED-'); Set($MailCommand, 'smtp'); Set($SMTPServer, '-CENSORED-'); Set($SMTPFrom , '-CENSORED-'); Set($NotifyActor , '1'); Set($OwnerEmail , 'root'); Set($MaxAttachmentSize , 1000); Set($DatabaseType, 'mysql'); Set($DatabaseUser , 'rt_user'); Set($DatabasePassword , '-CENSORED-'); Set($DatabaseName , 'rt4'); Set($WebPath , ); Set($WebBaseURL , http://-CENSORED-;); Set(@Plugins,qw(RT::Extension::BriefHistory)); 1; On Mon, May 23, 2011 at 1:42 PM, Kevin Falcone [1]falc...@bestpractical.com wrote: On Mon, May 23, 2011 at 09:09:08AM -0400, Chris Hall wrote: Seems after watching a few days this is still an issue. It seems completely random.. some pages just... take awhile to load for some reason. 15 - 20 seconds, and then you can blast through a few pages instantly it seems... completely random. I've checked the logs, no errors or anything that stands out. Some of the pages that slow down don't access replying via email, so SMTP wouldn't be the issue. I examined again my slow query logs for mysql and yesterday got this: None of these queries look like something generated by RT. RT's ORM has some... signatures it leaves on the query. Are you perhaps using some sort of backup or indexing tool, or an extension developed in-house? # Time: 110523 2:30:10 # User@Host: rt_user[rt_user] @ localhost [] # Query_time: 6 Lock_time: 0 Rows_sent: 70390 Rows_examined: 70390 use rt3; SELECT /*!40001 SQL_NO_CACHE */ * FROM `Attachments`; # Time: 110523 2:30:17 # User@Host: rt_user[rt_user] @ localhost [] # Query_time: 4 Lock_time: 0 Rows_sent: 125353 Rows_examined: 125353 SELECT /*!40001 SQL_NO_CACHE */ * FROM `Transactions`; # Time: 110523 2:30:20 # User@Host: rt_user[rt_user] @ localhost [] # Query_time: 3 Lock_time: 0 Rows_sent: 10343 Rows_examined: 10343 SELECT /*!40001 SQL_NO_CACHE */ * FROM `sessions`; If you'd like to try and examine SQL problems on a particular page, you can enable $StatementLog and examine the output from the Configuration - Tools page as a superuser. -kevin However, that's only 3 entries.. it happens much more often than that. I'm thinking I'll see the CPU peg out maybe 5 - 8 times in a 5 min span, for about 10 - 15 seconds each time watching top. My only thought is there's some type of a miscommunication between apache and mysql, but I have no idea what. At this point, I'm open to any and all suggestions. Please, if anybody has any suggestions on where to look, I'd appreciate it. On Thu, May 19, 2011 at 10:33 AM, Chris Hall [2]hir...@gmail.com wrote: Well, resolved the below a bit by adding to RT_SiteConfig.pm: Set($WebSessionClass, Apache::Session::File); However, CPU usage still peaks out on apache2 processes, although it appears to be not AS frequent. Anybody have any other suggestions on areas to look into? Some are saying the slowdown seems to occur most frequently when updating tickets. On Wed, May 18, 2011 at 8:36 PM, Chris Hall [3]hir...@gmail.com wrote: I actually saw something about that in a message to the mailing list, and already turned it off as well, as a precaution. After searching around some and trying out some tests, it seems the delay happens after the GET request to the apache server, and watching the logs, nothing appears in
Re: [rt-users] dashboard my reminders error after upgrade to RT 4
From my digging, it looks like reminders are actually implemented as separate tickets, but they don't really show up unless you go looking for them. I opened the tickets numbers that the dashboard was complaining about and resolved them, which seemed to correct the problem. Any potential issues that this may raise? On 5/20/11 12:54 PM, Jon Tollerton wrote: After upgrading to RT 4 from 3.8.10, I'm seeing several errors in the dashboard reminders section in the form Couldn't find Ticket for reminder N. Please contact administrator. Oddly enough, it displays on all users' dashboards. This seems to only affect two or three really old entries as we really don't use the reminder functionality. It's certainly possible that some data was corrupted by my mucking about in the database or by using RT-Shredder incorrectly before it was merged into the mainline, but I'm not sure where to start looking. Thanks, -Jon
