[Pgpool-general] connection limits

[Tatsuo Ishii]

> When you refer to the listen queue, are you talking about the number of
> sockets the kernel is configured to support?  I noticed that on Debian
> installs, this is set by default to 52374 and RedHat Enterprise to 465305.

No. I'm talking about listen(2)'s second parameter called "backlog".
See listen's man page for more details.
--
Tatsuo Ishii
SRA OSS, Inc. Japan

> On 12/17/05, Tatsuo Ishii <ishii at sraoss.co.jp> wrote:
> >
> > > I am curious what information I can get regarding connection limits per
> > > pgpool server.   I am sure there are several variables involved but my
> > > primary purpose for asking is to decided whether or not to have many
> > load
> > > balanced web servers talk to individual pgpool servers running locally
> > that
> > > each talk to various db servers in a replication pool or if I should
> > only
> > > have one pgpool server per db replicant.  There are advantages to both
> > > sides, however some understanding about the limitations (or lack of)
> > that
> > > pgpool has in the number of connections it can accept (app to pgpool,
> > not
> > > pgpool to pg), and what kind/measure of system resources are consumed
> > for
> > > those connections.
> > >
> > > I suspect it's probably not a deal breaker either way.
> >
> > The connection limits for app to pgpool is deinfed by
> > "num_init_children". For example, if num_init_children = 32, there are
> > 32 pgpool child processes and each process issues accept(2). Thus up
> > to 32 apps can connect to pgpool child processes. If 33th app tries to
> > connect to pgpool, the request will be blocked and added to the
> > kernel's listen queue. This is very different from
> > PostgreSQL(postmaster)'s behavior, in that postmaster will not accept
> > more than mx_connections request and just throws an error.
> >
> > Note that there is a limit for the length of listen queue. pgpool
> > tries to set the length as long as possible, but the actual length
> > will vary depending the kernel you are using (I'm not sure the exact
> > number). If your SQL pattern is heavy enough to run out the listen
> > queue, you might want to set larger value for num_init_children, or
> > start multiple pgpool instances as you suggest.
> > --
> > Tatsuo Ishii
> > SRA OSS, Inc. Japan
> >