[pgpool-general: 6186] Re: PGPOOL 3.7.3 on -m fast stop does not send the fin wait packet to all connections

[luca ceccarani]

Thanks for the reply.
I did more tests (stop pgpool on master node) capturing the traffic at
server side, but even from this point of view some of the established
connections didn't receive a fin packet from the server to close the
connection.
Anyway I'm quite satisfied handling this situation (dead established
connections at client side) using the keepalive parameters in the
connection string to pgpool.
By,
luca

Il gio 2 ago 2018, 07:18 Tatsuo Ishii <ishii at sraoss.co.jp> ha scritto:

> > Hi to all,
> > this is my frist email to this ml, and I would like to thanks all the
> > community working around the pgpool project.
> >
> > My current configuration is the following:
> > 2 servers both with pgpool 3.7.3 and postgresql 9.4.18 with bdr support
> and
> > watchdog enabled.
> >
> > Both pgpool and postgers are compiled from source code.
> >
> > Here below the relevant (I hope) configuration settings for pgpool:
> >
> > port = 5433
> > listen_backlog_multiplier = 2
> > serialize_accept = off
> >
> > num_init_children = 500
> > max_pool = 1
> > child_life_time = 300
> > child_max_connections = 0
> > connection_life_time = 0
> > client_idle_limit = 0
> >
> > load_balancing=on
> > master_slave_mode = on
> > master_slave_sub_mode = 'logical'
> >
> > use_watchdog = on
> >
> > In my current environment there are 6 clients and each of them establish
> > around 55-65 connections each. When all clients are running around 350
> > backend connections are established against the pgpool node where the VIP
> > is exposed.
> >
> > When the total amount of connections is around 350 the problem I'm
> > experiencing is the following : issuing as root a pgpool -m fast stop
> > command on the master pgpool, quite frequently, not all the connections
> > previously established by the client to the VIP are closed at the client
> > side.
> >
> > Issuing, as root, a netstat -antpd | grep 5433 on the client that has not
> > closed all connections, I can still see some connections in ESTABLISHED
> > state; obviously these connections are the ones the client had
> established
> > to the previous pgpool master.
> >
> > I've even run a tcpdump capture at the client side to check if a fin
> packet
> > was sent by the old pgpool master (the one holding the VIP) for all the
> > connections, but I got evidence, at least from those captures, that not
> all
> > connections,at client side, received a fin packet from server.
> >
> > Currently we handled this issue configuring in the connection string of
> our
> > client the tcp_keepalives parameters (interval=5, count=2, idle=20).
> > I was wondering if the lack of fin packet is dued to a bug or it could be
> > normal while stopping pgpool in fast mode.
> >
> > Regards,
> > luca
>
> In my understanding when Pgpool-II server exits by "pgpool -m fast
> stop", close(2) is automatically done by the kernel and FIN packet
> will be send out if the pgpool process has a socket to frontend. In
> another word, Pgpool-II doesn't need to do anything than call exit(3).
>
> As far as I know, PostgreSQL behaves like this when they exit.
>
> Best regards,
> --
> Tatsuo Ishii
> SRA OSS, Inc. Japan
> English: http://www.sraoss.co.jp/index_en.php
> Japanese:http://www.sraoss.co.jp
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.sraoss.jp/pipermail/pgpool-general/attachments/20180807/a3e7e89c/attachment.html>