[rt-users] AssetTracker crashes loading asset

[John]

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