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 <[EMAIL PROTECTED]> > To: John <[EMAIL PROTECTED]>, [email protected] > 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 <[EMAIL PROTECTED]> >>> To: John <[EMAIL PROTECTED]>, [email protected] >>> 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. >>>> >>>> [EMAIL PROTECTED] >>>> 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: [EMAIL PROTECTED] >>>> >>>> >>>> Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy >>>> a copy at http://rtbook.bestpractical.com >>>> >>>> >>>> >>> >>> >> >> [EMAIL PROTECTED] >> SDF Public Access UNIX System - http://sdf.lonestar.org > [EMAIL PROTECTED] 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: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
