I need some assistance with resolving an issue with bad NIS performance.
I have three systems set up as follows:
* NIS master running NetBSD 1.6.1
* NIS slave running NetBSD 1.6.1
* NIS client running FreeBSD 4.9-STABLE as of Nov. 17
Each of these machines is dual-homed talking to both a public network
and internal LAN. The public network interfaces are firewalled against
NIS requests and I have verified that both the client and slave are
properly YP bound to the internal interfaces.
The FreeBSD NIS client has very bad performance when doing NIS lookups
for authentication, e.g. POP e-mail, logins, sudo, even "finger".
After
doing a "truss" on a finger command, I can sort of see what is going
on,
but I cannot determine why. Here is what the (ellided) truss output
looks like at the problem area (I've replaced the real NIS domain with
"the_nis_domain" in the first line):
open("/var/yp/binding/the_nis_domain.2",0x0,05002420230) = 5 (0x5)
flock(0x5,0x6) ERR#35 'Resource
temporarily unavailable'
readv(0x5,0xbfbfecc4,0x2) = 14 (0xe)
close(5) = 0 (0x0)
break(0x8065000) = 0 (0x0)
gettimeofday(0xbfbfec08,0x0) = 0 (0x0)
getpid() = 33258 (0x81ea)
socket(0x2,0x2,0x11) = 5 (0x5)
getsockname(0x5,{ AF_INET 0.0.0.0:0 },0xbfbfeb1c) = 0 (0x0)
getsockopt(0x5,0x0,0x13,0xbfbfeb14,0xbfbfeb18) = 0 (0x0)
setsockopt(0x5,0x0,0x13,0xbfbfeb10,0x4) = 0 (0x0)
bind(0x5,{ AF_INET 0.0.0.0:0 },16) ERR#1 'Operation not
permitted'
setsockopt(0x5,0x0,0x13,0xbfbfeb14,0x4) = 0 (0x0)
ioctl(5,FIONBIO,0xbfbfec04) = 0 (0x0)
fcntl(0x5,0x2,0x1) = 0 (0x0)
bind(0x5,{ sa_len = 0, sa_family = 0, sa_data = { } },16) 0 (0x0)
getsockname(0x5,{ AF_INET 0.0.0.0:2313 },0xbfbfecb4) = 0 (0x0)
sendto(0x5,0x8064968,0x48,0x0,0x8064008,0x10) = 72 (0x48)
gettimeofday(0xbfbfeff0,0x0) = 0 (0x0)
select(0x6,0xbfbff060,0x0,0x0,0xbfbfefe8) = 1 (0x1)
recvfrom(0x5,0x8064068,0x900,0x0,0xbfbff050,0xbfbfefcc) = 104 (0x68)
getpid() = 33258 (0x81ea)
The last few lines starting with "getsockname" repeat about 1,340
times
before 'finger' returns any useful information. Obviously this is the
source of the problem, as on the NIS slave, this does not occur -
'finger' returns after a couple such calls.
Does anyone have any ideas about where I should start looking to try and
resolve this problem? Obviously NIS is *eventually* deciding that it's
found the information it's looking for, and returns, but the >1000 extra
network reads are inexplicable to me.
- Julian
--
[ Julian C. Dunn <jdunn@aquezada.com> * <julian@dreaming.org>
]
[ WWW: www.aquezada.com/staff/julian/ * www.dreaming.org/~julian/ ]
[ PGP: 0xFDC205B9 - 91B3 7A9D 683C 7C16 715F 442C 6065 D533 FDC2 05B9 ]
[ "sometimes you win, sometimes you lose / and most times ]
[ you choose between the two" - carole king, "sweet seasons"
]