Apache FastCGI and # of db connections

RT Users
1

Hi,

Thanks very much for Request Tracker!

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.

I am using Debian Wheezy (with some packages from Jessie/Sid to satisfy
dependencies) and PostgreSQL as database backend on it.

I have a four instances of RT connecting to one PostgreSQL server.
FastCGI processes of my old instances (3.8.16) was configured in the
Apache:

FastCgiServer /opt/eu/bin/mason_handler.fcgi -idle-timeout 400 -processes 9 -init-start-delay 1
FastCgiServer /opt/interni/bin/mason_handler.fcgi -idle-timeout 400 -processes 2 -init-start-delay 2
FastCgiServer /opt/nis/bin/mason_handler.fcgi -idle-timeout 400 -processes 9 -init-start-delay 2
FastCgiServer /opt/RT/bin/mason_handler.fcgi -idle-timeout 400 -processes 9 -init-start-delay 1

So I have a total number of 3 * 9 + 2 = 29 FastCGI processes and the
same number of database connections:

rt=# select count(*) from pg_stat_activity where usename like ‘rt_%’;
count
29
(1 row)

Note: all RT DB accounts starts with `rt_'.

I have limited number of database connection on the server:
rt:~# grep ^max_connections /etc/postgresql/9.1/main/postgresql.conf
max_connections = 48 # (change requires restart)

And this number (48) is sufficient so.

During testing of RT 4.2.1 instances on the testing box with modified
configuration according to web_deployment.pod I got after a while exhausted
database connections.
I noticed every FastCGI process forks one child (Placks default?), that
delays database connection to HTTP request time, so I ended up with two
times number of DB connections than before.

I tried to configure one fresh instance:

<Directory “/opt/rt4-preview” >
Options FollowSymLinks ExecCGI
AllowOverride None

FastCgiServer /opt/rt4-preview/sbin/rt-server.fcgi -processes 5 -idle-timeout 300
ScriptAlias /rt4 /opt/rt4-preview/sbin/rt-server.fcgi

this is according to docs/web_deployment.pod I hope.

During Apache startup, it is possible for a moment to see processes:
_ /usr/bin/perl -w /opt/rt4-preview/sbin/rt-server.fcgi
which quickly transforms into daemonized couple:
_ perl-fcgi-pm
| _ perl-fcgi

After a while the situation is (pstree):
├─apache2─┬─apache2─┬─5*[perl-fcgi-pm───perl-fcgi]
│ │ └─3*[rt-index.fcgi]
│ └─5*[apache2]

Till no request is handled the connections are:
zito=# select count(*) from pg_stat_activity where usename like ‘rt_%’;
count
5
(1 row)

The number of connections grows during requests on web interface and ends with:
zito=# select count(*) from pg_stat_activity where usename like ‘rt_%’;
count
10
(1 row)

All children processes are connected to database…

Is this setup really ok?

I did not study Plack too much - only look at

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

But I don’t know technology.
Should I really increase PostgreSQL max_connections to 100 and don’t
bother with it?
Best Regards
Zito

2

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 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.

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
3

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