On 20/06/2023 15:41, Gary Jennejohn wrote:
On Tue, 20 Jun 2023 12:04:13 +0200 Alexander Leidinger<alexan...@leidinger.net> wrote:Quoting Gary Jennejohn<ga...@gmx.de> (from Tue, 20 Jun 2023 07:41:08 +0000):…In other words the software listening on it didn't process the request fast enough and a backlog piled up (e.g apache ListenBacklog or nginx "listen X backlog=y" and "sysctl kern.ipx.somaxconn=X" for FreeBSD itself). You may need faster hardware, more processes/threads to handle the traffic, or configure your software to do less to produce the same result (e.g. no real-time DNS resolution in the logging of a webserver or increasing the amount of allowed items in the backlog). If you can change the software, there's also the possibility to switch from blocking sockets to non-blocking sockets (to not have the select/accept loop block / run into contention) or kqueue.On my FreeBSD14 system these things are all under kern.ipc. maxconn seems to be an alias for soacceptqueue, which is set to 128 on my machine. However, the software he's using may have set backlog to 1. Hard to say based on the trace he provided.
Thanks, people.A few hours ago I took a hint from one of the pages linked from <https://dan.langille.org/2020/01/01/listen-queue-overflow/>, added a line to my sysctl.conf(5).
% sysctl kern.ipc.soacceptqueue kern.ipc.soacceptqueue: 256 % sysctl kern.ipc.maxconn sysctl: unknown oid 'kern.ipc.maxconn' % sysctl kern.ipc.somaxconn kern.ipc.somaxconn: 256 % grep ipc /etc/sysctl.conf kern.ipc.soacceptqueue=256 %I began wondering about the sonewconn lines in relation to <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270997> for net-mgmt/netdata, although I don't know whether there's a direct relationship.
% netstat -Lan | grep netdata unix 0/0/128 /tmp/netdata-ipc % My use of Netdata is local-only.
OpenPGP_signature
Description: OpenPGP digital signature
