Re: [PERFORM] Many connections lingering

От Tom Lane
Тема Re: [PERFORM] Many connections lingering
обсуждение исходный текст
Ответ на Re: [PERFORM] Many connections lingering  (Greg Stark)
Список pgsql-novice
Дерево обсуждения
Many connections lingering  (Slavisa Garic, )
 Re: Many connections lingering  (Tom Lane, )
  Re: [PERFORM] Many connections lingering  (Greg Stark, )
   Re: [PERFORM] Many connections lingering  (Tom Lane, )
   Re: [PERFORM] Many connections lingering  (Slavisa Garic, )
    Re: [PERFORM] Many connections lingering  (John DeSoi, )
    Re: [PERFORM] Many connections lingering  (Mark Lewis, )
 Re: [PERFORM] Many connections lingering  (Slavisa Garic, )
Greg Stark <> writes:
> Tom Lane <> writes:
>> This is a network-level issue: the TCP stack on your machine knows the
>> connection has been closed, but it hasn't seen an acknowledgement of
>> that fact from the other machine, and so it's remembering the connection
>> number so that it can definitively say "that connection is closed" if
>> the other machine asks.

> No, what Tom's describing is a different pair of states called FIN_WAIT_1 and
> FIN_WAIT_2. TIME_WAIT isn't waiting for a packet, just a timeout.

D'oh, obviously it's been too many years since I read Stevens ;-)

So AFAICS this status report doesn't actually indicate any problem,
other than massively profligate use of separate connections.  Greg's
correct that there's some risk of resource exhaustion at the TCP level,
but it's not very likely.  I'd be more concerned about the amount of
resources wasted in starting a separate Postgres backend for each
connection.  PG backends are fairly heavyweight objects --- if you
are at all concerned about performance, you want to get a decent number
of queries done in each connection.  Consider using a connection pooler.

            regards, tom lane

В списке pgsql-novice по дате отправления:

От: "Cima"
Сообщение: error handling
От: David Orme
Сообщение: Re: SUMMARY - select top N entries from several groups