> On 26. Sep 2019, at 12:40, Otto Moerbeek <[email protected]> wrote:
>
> On Thu, Sep 26, 2019 at 11:16:21AM +0200, Joerg Jung wrote:
>
>> Hi,
>>
>> I run a few busy (~800 req/s) NSD servers which I upgraded
>> to 6.5, all stock/default OpenBSD, e.g. I’ve not tweaked any
>> sysctl values and nsd.conf matches the default as well, just
>> added a few hundred zones.
>>
>> Now, when I increase servers from default 1 to 2 in nsd.conf:
>> server-count: 2
>> it starts spamming my log with:
>> nsd[62723]: sendto 1.2.3.4 failed: Resource temporarily unavailable
>>
>> checking the source, server.c seems not to handle EAGAIN
>> after sendto() and does not recover or retry, it just increases
>> txerr statistic count - so answer seems really lost :(
>>
>> I tried higher debug level, as well as increasing socket buffers to:
>> net.inet.udp.recvspace= 65536
>> net.inet.udp.sendspace=65636
>> but both didn’t help and netstat -s -p udp does show
>> 0 dropped due to full socket buffers
>> anyways. So, I don’t believe this is a socket buffer issue.
>>
>> The same server-count: 2 setting worked fine with 6.3.
>>
>> Any hints, insights, or pointers?
>> Does anyone else experience the same?
>
> This is likely an fd limit issue. Try:
>
> nsd:\
> :openfiles=512:\
> :tc=daemon:
>
> in login.conf, followed by a restart of nsd.
Thanks for reply. Tried that, but unfortunately did not help.
I checked with fstat, and each of the NSD processes has not much
more than 16 fds open, while complaining loudly in log about
sendto() EAGAIN
From what I understand TCP for (A|I)XFR transfers are also limited to
max 100 TCP connections by default (and would show up with “too
many open files” or similar).
So, should all more or less fit into the daemon class defaults.
Also this sendto() part of the server.c code seems not really changed
between 6.3 and 6.5 so, must be something different. Might be changes
in libevent or thread mutex handling, or something…
