Re: Bug (and fix): leaks of TCP connections when connected
От | Tom Lane |
---|---|
Тема | Re: Bug (and fix): leaks of TCP connections when connected |
Дата | |
Msg-id | 8806.1087868552@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Bug (and fix): leaks of TCP connections when connected (Kris Jurka <books@ejurka.com>) |
Список | pgsql-jdbc |
Kris Jurka <books@ejurka.com> writes: > I'm not much of an expert on TCP, so could you give me a little more > background on this? I've duplicated the behavior you describe and I > believe your fix is correct, but I'd like to understand this better. > First why is this a problem, the CLOSE_WAIT entries disappear rather > quickly. Second the number of CLOSE_WAIT items is nothing compared to the > number of TIME_WAIT entries, why aren't they a problem? I think CLOSE_WAIT means that the kernel knows the far end has closed the connection, but it's not yet been able to tell the local client so (the vice-versa case may be called this too, not sure). This state can persist indefinitely if the client is uncooperative. TIME_WAIT is a short-lived state; the connection will be forgotten completely after the timeout, which I think is order-of-a-minute. (TIME_WAIT exists only so that the kernel remembers what to do with any delayed packets that may arrive from the far end.) Bottom line is that CLOSE_WAIT means that a client bug is keeping the kernel from freeing resources. You don't want to see that. regards, tom lane
В списке pgsql-jdbc по дате отправления: