<p>Loading less translations of the interface saves memory. Module that parses po files is not memory efficient and I can't find cycles to improve it.</p>
<p>Using RT on Apache with mod_perl without reverse proxy in front is also memory hungry setup. Use reverse proxy for mod_perl setups.</p>
<p>Simple fastcgi is a little bit better as web server acts like proxy and one fastcgi process may serve several server processes. However, each fastcgi process started on its own by web server and don't share memory.</p>

<p>Recent RT versions have external fastcgi server that uses forks and shares memory.</p>
<p>I think external forking fastcgi server with nginx/lighttpd/Apache in front may give most memory effective setup. </p>
<p>Regards, Ruslan. From phone.</p>
<div class="gmail_quote">26.08.2011 14:07 пользователь "Christian Loos" <<a href="mailto:cloos@netcologne.de">cloos@netcologne.de</a>> написал:<br type="attribution">> Am 24.08.2011 15:48, schrieb Gilbert Rebeiro:<br>
>> Understood, I have upgraded the memory to 2GB.<br>>> Let's see how it works.<br>> <br>> Which RT Version do you run?<br>> <br>> It would be great if you could share your experiences with me.<br>
> <br>> We moved your RT 3.8.6 some weeks ago from a 32bit Debian lenny machine <br>> to a 64bit Debian squeeze VM with 4GB RAM.<br>> Since then the apache processes eating up all the memory.<br>> As we don't changed the RT Version I think it's not RT fault.<br>
> I guess there is a memory leak in one of the Perl modules.<br>> <br>> We use all the Perl modules from the Debian repository.<br>> <br>> -Chris<br>> --------<br>> RT Training Sessions (<a href="http://bestpractical.com/services/training.html">http://bestpractical.com/services/training.html</a>)<br>
> *  Chicago, IL, USA  September 26 & 27, 2011<br>> *  San Francisco, CA, USA  October 18 & 19, 2011<br>> *  Washington DC, USA  October 31 & November 1, 2011<br>> *  Melbourne VIC, Australia  November 28 & 29, 2011<br>
> *  Barcelona, Spain  November 28 & 29, 2011<br></div>