Recursive bind becomes unresponsive with high load
Michael Brunnbauer
brunni at netestate.de
Sat Apr 2 13:19:09 UTC 2016
Hello Mike,
connection tracking does not seem to be the issue here. I see no messages
about packets dropped from the kernel and I have not loaded the relevant
modules (iptable_nat, ip_conntrack, etc.) anyway.
Regards,
Michael Brunnbauer
On Fri, Apr 01, 2016 at 09:48:01PM +0000, Mike Mitchell wrote:
> Have you checked the Kernel's connection tracking statistics?
> Here's a link:
> https://kb.isc.org/article/AA-01183/0/Linux-connection-tracking-and-DNS.html
>
> I've had to increase some network parameters on our busy nameservers. I put the following in /etc/sysctl.conf
>
> net.netfilter.nf_conntrack_udp_timeout_stream = 45
> net.nf_conntrack_max = 500000
> net.ipv4.neigh.default.gc_thresh1 = 512
> net.ipv4.neigh.default.gc_thresh2 = 1024
> net.ipv4.neigh.default.gc_thresh3 = 2048
> net.ipv4.tcp_max_syn_backlog = 4096
> net.ipv4.tcp_fin_timeout = 30
> net.ipv4.tcp_tw_recycle = 1
>
> Mike Mitchell
>
> ________________________________________
> From: bind-users-bounces at lists.isc.org <bind-users-bounces at lists.isc.org> on behalf of Michael Brunnbauer <brunni at netestate.de>
> Sent: Friday, April 1, 2016 12:29 PM
> To: Mathew Ian Eis
> Cc: dot at dotat.at; bind-users at lists.isc.org
> Subject: Re: Recursive bind becomes unresponsive with high load
>
> Hello Mathew,
>
> On Fri, Apr 01, 2016 at 04:01:04PM +0000, Mathew Ian Eis wrote:
> > What OS are you running your BIND server on? Is it virtualized?
>
> Linux Kernel 3.4.111 with glibc 2.22, 32bit, not virtualized. No distribution -
> everything was compiled by hand.
>
> > Is it fully unresponsive, or could it be simply taking longer to respond than your client timeout?
>
> Assuming that bind would report dropped queries, I guess it is the latter.
>
> Regarding the suggestion made by Tony Finch about too many TCP connections
> in the TIME_WAIT status: That would have been a good explanation. But I do not
> see more than 200 TCP connections in TIME_WAIT status when the problem occurs
> and not more than 5000 TCP/UDP connections with port 53.
>
> cu,
> brunni
>
> --
> ++ Michael Brunnbauer
> ++ netEstate GmbH
> ++ Geisenhausener Straße 11a
> ++ 81379 München
> ++ Tel +49 89 32 19 77 80
> ++ Fax +49 89 32 19 77 89
> ++ E-Mail brunni at netestate.de
> ++ http://www.netestate.de/
> ++
> ++ Sitz: München, HRB Nr.142452 (Handelsregister B München)
> ++ USt-IdNr. DE221033342
> ++ Geschäftsführer: Michael Brunnbauer, Franz Brunnbauer
> ++ Prokurist: Dipl. Kfm. (Univ.) Markus Hendel
--
++ Michael Brunnbauer
++ netEstate GmbH
++ Geisenhausener Straße 11a
++ 81379 München
++ Tel +49 89 32 19 77 80
++ Fax +49 89 32 19 77 89
++ E-Mail brunni at netestate.de
++ http://www.netestate.de/
++
++ Sitz: München, HRB Nr.142452 (Handelsregister B München)
++ USt-IdNr. DE221033342
++ Geschäftsführer: Michael Brunnbauer, Franz Brunnbauer
++ Prokurist: Dipl. Kfm. (Univ.) Markus Hendel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20160402/85415fcf/attachment.bin>
More information about the bind-users
mailing list