On Fri, Jan 10, 2014 at 07:13:28PM -0500, Alex Vandiver wrote: > On Fri, 2014-01-10 at 11:45 +0100, Václav Ovsík wrote: > > I have a question regarding behaviour of FastCGI processes and database > > connections. While preparing upgrade of RT 3.8.16 to RT 4.2.1 I noticed > > a change of FastCGI usage in the RT. > > Thanks for bringing this to our attention. This is a bug which affects > RT 4.0 and 4.2; the 4.0/fewer-active-handles branch resolves the issue.
I have applied changes from your new branch and database handles are OK now. > > I did not study Plack too much - only look at > > http://search.cpan.org/~miyagawa/Plack-1.0030/lib/Plack/Handler/FCGI.pm > > and there is approach a bit different. One daemon is started standalone > > (forking to a number of processes) and Apache is configured to connect > > to this daemon > > FastCgiExternalServer /tmp/myapp.fcgi -socket /tmp/fcgi.sock > > This is a valid alternate deployment strategy, which comes with the > benefit that one can restart one RT server without affecting others, by > restarting its fastcgi process. However, it requires additional system > configuration to ensure that these processes are started at server > startup time, and so forth, which is why this is not the deployment > suggested in RT's documentation, which we aim to keep as simple as > possible. I understand it. > > Should I really increase PostgreSQL max_connections to 100 and don't > > bother with it? > > Until a version of RT is released with the above branch, increasing the > max_connections is likely your best bet. The additional connections > will consume some small amount of memory each, but this is likely > negligible, and will have no performance impact. > - Alex I have GIT versioned installed RT files, so no problem to apply some changes directly into installed RT instances. Thanks for quick response and good job! Best Regards -- Zito
