OK, so thread 13 is waiting on conn 1370, sd 39. There are actually no error
messages associated with this connection or socket anywhere in your logs.
Likewise for thread 16: conn 1351, sd 20. No errors anywhere.
This looks more like a problem with epoll() than anything else. Are the
connections associated with socket 20 and 39 actually dead?

The process which initiated those connections is gone; the test harness
runs

slamd (a load generator) repeatedly and then kills it while it is running, to
simulate the connections going down in a variety of states. Interestingly,
though, here’s the lsof output for the slapd file descriptors:

Most of the TCP connections are in CLOSE_WAIT, which is what you’d expect
if

the client sent a FIN but the server is frozen and cannot close the socket.
However, note the odd state of the two sockets you asked about, 20 and 39:
“can’t identify protocol.” There are 25 IPv4 connections in CLOSE_WAIT shown
above; by comparison, netstat shows all those, plus one more on port 43362 not
shown above.

Something else to try would be to disable the use of epoll() and go back to
select(), to see if this problem is epoll-specific. In slapd/daemon.c, after
the #include "portable.h" add a #undef HAVE_EPOLL and then recompile and test.