Maintained by: NLnet Labs

[Unbound-users] TCP random timeouts

W.C.A. Wijngaards
Tue Nov 16 09:24:43 CET 2010


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Thomas,

On 11/16/2010 03:14 AM, Thomas Guthmann wrote:
>> This indicates the remote end closed read the read end of the tcp
>> channel. [..]
> Ok. I think they happen more when unbound seems to struggle to resolve
> TCP queries. Indeed if recursion takes too long, the client closes the
> connection after a defined timeout.

Could it be that the 10 connections that unbound offers simultaneously
are simply swamped with traffic, and thus the new query cannot get in?
Since unbound is not accepting new tcp connections, the client times out
trying to establish a tcp connection?

In the config there is the setting:
        # outgoing-num-tcp: 10
        # incoming-num-tcp: 10

Perhaps if you increase them, say to 50, you have more capacity to
handle tcp connections?

Since you did not compile with libevent, you do have a limit there,
certainly as compared to your 950 outgoing-range.  If you used libevent,
you could simply state the number you want (it takes about 65k for every
buffer); so 100 or 200 would be a lot.

> @UNBOUND_IP". I tried locally when it seems stuck and I have the same
> behaviour. How can I distinguish the TCP from the UDP queries in a
> unbound dump_requestlist ?

It does not show that.

> For the moment, my problem hasn't occurred again but I know it will. I
> will try to do more debugging next time to see if it's unbound or
> something else.

thanks

> Also I forgot to paste my current config. Each server has 1G of memory
> and unbound used ~760M once the cache is full. Servers are not heavily
> used yet (see stats below over a ~5min period of time).

You seem to have more TCP traffic than others, but unbound would print a
num_tcp statistic as well; but you did not include it in your excerpt.
Or worse, there was none (it was zero?), and unbound reports it has
received no TCP queries, but you tried to?  Since the connection
establishment could be the issue, a tcpdump of the tcpconnection tryout
(from the client) could be nice; to see if it managed to connect.

Best regards,
   Wouter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkziP8sACgkQkDLqNwOhpPhSgACeO8dRt4cBfBms3LQ3ahw9HA6H
PY8AoInMMrq19j5dpbaiUTsh+2+KbNli
=e4By
-----END PGP SIGNATURE-----