Hello everyone, To cut a long story short, my question is - Is it possible to run multiple different apache instances per a single RT database with a sufficient transactional support, provided that different RT front-ends don't share a single address space, a single <RT_ROOT>/var and apache process-specific files, like pidfile? The reason for it is explained below.
Our current configuration is rt-3.6.4 (heavily customized) running on Apache/2.2.4 + mod_perl/2.0.3(DSO) + Perl/v5.8.8. DBMS backend is PostgreSQL/8.2.3, data size is approximately 62Gb. New requests enter our RT instance through procmail recipes. All is running quite smooth, but there's quite a critical issue with apache: when it gets signalled with SIGHUP or SIGUSR1 (for instance, with newsyslog), its root process grows significantly in memory consumption, namely, Resident Set Size. Therefore, child processes inherit this grows, too. It's quite a typical behavior for mod_perl, according for its documentation. I'd call it memory leak. :( For now, I'm thinking of setting up syslogd to care of apache and RT logs... As rt-mailgate works through RT REST API, some requests end up at maildir if there's no apache running at their arrival. I have written a watchdog script which does its best in feeding unlucky requests back to RT (through procmail). I'll likely share it soon, if anyone is interested. Now I plan on configuring a totally separate apache+mod_perl+RT codebase instance for emails - our requests are preprocessed quite heavily, and it can be really memory-heavy, but this very apache instance can be configured with MaxRequestsPerChild=1. Is it possible? Would it help? What are the drawbacks of the suggested approach? Is there any better suggestion? What about fastcgi, is it simple and configurable enough to enforce different requirements on robustness and scalability on per-task basis? I am looking for your feedback, any kind of help would be appreciated, thanks a lot! -- Viktor _______________________________________________ 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
