Allan Streib <astr...@indiana.edu> writes:
> Running a rather busy ldapd host, and seeing some hangs in responses to
> queries.
I see that fstat -u _ldapd always ends at FD 119 when the hang occurs:
[...]
_ldapd ldapd 42641 112* internet stream tcp 0x0 172.16.0.169:389 <--
172.16.0.38:44708
_ldapd ldapd 42641 113* internet stream tcp 0x0 172.16.0.169:389 <--
172.16.0.45:43392
_ldapd ldapd 42641 114* internet stream tcp 0x0 172.16.0.169:389 <--
172.16.0.26:54300
_ldapd ldapd 42641 115* internet stream tcp 0x0 172.29.202.69:389 <--
172.29.200.100:36250
_ldapd ldapd 42641 116* internet stream tcp 0x0 172.29.202.69:389 <--
172.29.200.109:45362
_ldapd ldapd 42641 117* internet stream tcp 0x0 172.29.202.69:389 <--
172.29.200.108:47864
_ldapd ldapd 42641 118* internet stream tcp 0x0 172.29.202.69:389 <--
172.29.200.104:56746
_ldapd ldapd 42641 119* internet stream tcp 0x0 172.29.202.69:389 <--
172.29.200.106:40436
I tried the following:
Gave _ldapd a login class of "ldap"
Added to login.conf:
ldap:\
:openfiles=512:\
:tc=daemon:
restart ldapd.
Still hangs with fstat output the same.
$ vmstat
procs memory page disks traps cpu
r s avm fre flt re pi po fr sr sd0 sd1 int sys cs us sy id
1 70 44M 22728M 5 0 0 0 0 0 0 0 25 79 84 0 0 100
$ netstat -m
444 mbufs in use:
220 mbufs allocated to data
168 mbufs allocated to packet headers
56 mbufs allocated to socket names and addresses
180/520 mbuf 2048 byte clusters in use (current/peak)
0/30 mbuf 2112 byte clusters in use (current/peak)
0/64 mbuf 4096 byte clusters in use (current/peak)
0/72 mbuf 8192 byte clusters in use (current/peak)
0/42 mbuf 9216 byte clusters in use (current/peak)
0/50 mbuf 12288 byte clusters in use (current/peak)
0/40 mbuf 16384 byte clusters in use (current/peak)
0/16 mbuf 65536 byte clusters in use (current/peak)
4520/5008/524288 Kbytes allocated to network (current/peak/max)
0 requests for memory denied
0 requests for memory delayed
0 calls to protocol drain routines
