[rt-users] RT 3.6.5 causes connection aborts resulting in 500 error

Kage kagekonjou at gmail.com
Wed May 20 09:41:56 EDT 2009


Same error is occurring with 1GB of memory on the VM.  Everything else
in Apache works just fine, but RT is dead until I restart Apache2.

On Wed, May 20, 2009 at 9:13 AM, Kage <kagekonjou at gmail.com> wrote:
> Memory capacity is currently set to 512MB on our Hardy RT VM.  CPU is
> capped to a whole core for itself (so, something like 2.8GHz).  Usage
> is practically none.  I'm not so sure memory is the issue, but I'll
> bump the VM's memory up and start pounding the Hardy RT VM and see if
> that fixes it.
>
> On Tue, May 19, 2009 at 6:21 PM, Nick Geron <ngeron at corenap.com> wrote:
>> Kage,
>>
>> I'm seeing similar issues with 3.8.2.  Take a look at my post "apache/mason
>> software caused connection abort."
>>
>> Running with Tom's thought, maybe we can compare setups.  My two systems are
>> identical builds of a gentoo stage 4 on VMWare ESX3i.  My default vm
>> resources are pretty low.  Each host has 256M and a single, virtual cpu
>> witch the systems see as a Xeon E5410.  Now I don't see how a nearly idle
>> system (in testing) could have resource issues with regard to the CPU, but
>> looking at my puny alloted memory, I could see how that might cause a
>> crunch.
>>
>> What's your memory capacity and usage look like?
>>
>> -Nick
>>
>> Tom Lahti wrote:
>>>
>>> Kage wrote:
>>>>>
>>>>> Essentially what happens is I can use RT for an extended period of
>>>>> time (from 1 hour to 10 hours), and eventually, it'll stop working,
>>>>> resulting in a 500 Internal Server Error.
>>>
>>> Sounds like resource exhaustion of some kind, perhaps a memory or some
>>> other
>>> type of leak in mason, perl, apache, or RT.  I hate to be vague, but it
>>> could be anything.  You probably need to step outside "what is in hardy's
>>> repository" and start upgrading things, probably starting with perl
>>> itself.
>>>
>>> But I would start by looking for more clues when the system is in the "not
>>> working" state.  Look at memory usage, CPU usage, and the like.  See if
>>> apache is responding to other non-RT page requests.  Doing so will help
>>> you
>>> narrow it down.
>>>
>>
>>
>
>
>
> --
> ~ Kage
> http://vitund.com
> http://hackthissite.org
>



-- 
~ Kage
http://vitund.com
http://hackthissite.org



More information about the rt-users mailing list