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
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 sea
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 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 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 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] @
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 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 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 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 wr
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
[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, 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] 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 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 > > >
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
On Mon, May 23, 2011 at 02:45:05PM +0100, Gary Holmes wrote: >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. All your questions are answered in the RT_Config.pm file ;) For FTS: =item C<%FullTextSearch> Full text search (FTS) without indexes is a very slow operation and by default is disabled at all. To enable FTS set key 'Enable' to 1. Setup of indexes and filling them with data requires additional steps that vary from DB to DB. Use F helper for quick start. This script creates required structures in the DB and gives some ideas on next steps. Use F to keep the index in sync. =cut [...] For LifeCycle: =head1 Lifecycles =head2 Lifecycle definitions Each lifecycle is a list of possible statuses split into three logic sets: B, B and B. Each status in a lifecycle must be unique. (Statuses may not be repeated across sets.) Each set may have any number of statuses. [...]
[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] 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 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 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 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 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?
>>>
>>>
>>>
>>
>
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=ASC&OrderBy=id&Query=(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 ”
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/
