[rt-users] AssetTracker crashes loading asset
nimbius at sdf.lonestar.org
Fri Nov 7 13:05:30 EST 2008
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.
> John wrote:
>> 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,
>>>> 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
>>>> 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
More information about the RT-Users