[rt-users] AssetTracker crashes loading asset

[Curtis Bruneau]

That's around near the limit of what I can pull in. While you are 
probably right with it being isolated, 20 seconds does seem a little 
suspect. I'm curious how much memory is being used during that call. We 
have a lot of attachments which makes each record rather large at times. 
If you do end up finding a solution to your problem I'm curious to hear it.

John wrote:
> hrm...i just pulled in a list of 47,000 RT tickets and was able to 
> load a single ticket after a time of about 20 seconds...seemed normal.
> have you tried Set($LogToSyslog , 'alert'); as a solution?
>
> this seems isolated to assettracker...i think...
>
> On Fri, 7 Nov 2008, Curtis Bruneau wrote:
>
>> Date: Fri, 07 Nov 2008 13:12:53 -0500
>> From: Curtis Bruneau <curtisb at vianet.ca>
>> To: John <nimbius at sdf.lonestar.org>, rt-users at lists.bestpractical.com
>> Subject: Re: [rt-users] AssetTracker crashes loading asset
>>
>>   While my issue is not related to asset tracker, the behavior sounds 
>> identical. It seems to be related to how RT handles search and 
>> display, the only thing I can think of is the menu on the left, It 
>> has to determine the first and last record and also next and prev, I 
>> think it's doing a full scan to figure it out.. pretty intensive 
>> operation, It would be better if it didn't have to deal with table.* 
>> and say only table.ticketid.
>>
>> <<First
>> < Prev
>> #12345
>> Next >
>> Last >>
>>
>> Sorry for the confusion, could just be a coincidence.
>>
>> Curtis
>>
>> John wrote:
>>>
>>> not certain it makes much sense...ive never had this problem in rt 
>>> 3.4.5 with at 1.2.3..
>>>
>>>
>>> On Fri, 7 Nov 2008, Curtis Bruneau wrote:
>>>
>>>
>>>
>>>> Date: Fri, 07 Nov 2008 12:52:04 -0500
>>>> From: Curtis Bruneau <curtisb at vianet.ca>
>>>> To: John <nimbius at sdf.lonestar.org>, rt-users at lists.bestpractical.com
>>>> Subject: Re: [rt-users] AssetTracker crashes loading asset
>>>>
>>>> The queries would execute fine, the problem at least in my case is 
>>>> it tries to load the whole result set into memory causing 
>>>> oom-killer to go on rampage. Apache will peak out, to sort of help 
>>>> this situation I added a mem limit to the fastcgi handler which 
>>>> will basically die before things get really ugly. I'm able to see 
>>>> this query in the log, it has no limit clause so it really is 
>>>> getting everything. While doing a form of debug/trace on the 
>>>> apache/handler I'm also able to see it trying to load the full row 
>>>> times search results (table.*) into memory. This is all on a ticket 
>>>> display from a large search result. So unless you are loading it in 
>>>> memory as opposed to say a shell client output you won't run into 
>>>> memory problems.
>>>>
>>>> Best of luck with your situation, I have not been able to get any 
>>>> confirmation until now with you. I've produced somewhat detailed 
>>>> bug report but it appears to be somewhat isolated.. people with low 
>>>> tickets will never run into this problem.
>>>>
>>>> Curtis
>>>>
>>>> John wrote:
>>>>> curtis:
>>>>> ive played around re-executing the mysql queries related to the RT 
>>>>> crash, and to no avail.  they execute just fine.
>>>>>
>>>>> could this perhaps be a syslog issue like in RT?  is there a 
>>>>> seperate control for syslogging in AT?
>>>>>
>>>>>
>>>>> On Fri, 7 Nov 2008, Curtis Bruneau wrote:
>>>>>
>>>>>> Date: Fri, 07 Nov 2008 10:43:48 -0500
>>>>>> From: Curtis Bruneau <curtisb at vianet.ca>
>>>>>> To: John <nimbius at sdf.lonestar.org>, 
>>>>>> rt-users at lists.bestpractical.com
>>>>>> Subject: Re: [rt-users] AssetTracker crashes loading asset
>>>>>>
>>>>>> Sounds exactly like the issue I have, I think something is trying 
>>>>>> to get all those records, I tried to trace it but with no luck, I 
>>>>>> think it may be related to the back/next links on the ticket 
>>>>>> display page. It's checking each record for something, This is ok 
>>>>>> with small results but crashes with large sets. I really wish I 
>>>>>> could figure this one out, I get the occasional 500 and users are 
>>>>>> made aware to keep search results smaller. In my testing this 
>>>>>> affected 3.4.x 3.6.x and 3.8.x
>>>>>>
>>>>>> John wrote:
>>>>>>> well, just as i thought the RT slowness issue had been resolved, 
>>>>>>> assettracker
>>>>>>> is now dying when loading a ticket out of a large list.
>>>>>>>
>>>>>>> example:  clicking "all assets" enumerates a 9000 row list fine,
>>>>>>> but clicking on any element in the list will crunch for a while
>>>>>>> then die with a 500 error.
>>>>>>>
>>>>>>> smaller lists with say 1000-3000 rows are sluggish when loading
>>>>>>> an asset from the list, but succeed.
>>>>>>>
>>>>>>> nimbius at sdf.lonestar.org
>>>>>>> SDF Public Access UNIX System - http://sdf.lonestar.org
>>>>>>> _______________________________________________
>>>>>>> http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
>>>>>>>
>>>>>>> Community help: http://wiki.bestpractical.com
>>>>>>> Commercial support: sales at bestpractical.com
>>>>>>>
>>>>>>>
>>>>>>> Discover RT's hidden secrets with RT Essentials from O'Reilly 
>>>>>>> Media. Buy a copy at http://rtbook.bestpractical.com
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> nimbius at sdf.lonestar.org
>>>>> SDF Public Access UNIX System - http://sdf.lonestar.org
>>>>
>>>
>>> nimbius at sdf.lonestar.org
>>> SDF Public Access UNIX System - http://sdf.lonestar.org
>>>
>>>
>>
>>
>
> nimbius at sdf.lonestar.org
> SDF Public Access UNIX System - http://sdf.lonestar.org
>
>