Hi,
I have both linux and solaris NIS client against a Solaris NIS Server, but my linux box are shamefully slow compare to solaris some sample:
on Solaris 5.8:
# ypwhich transporter02.domain.com # time id userid uid=36923(userid) gid=36923(u_036923)
real 0.0 user 0.0 sys 0.0
on Linux:
[root@linux]# ypwhich transporter02.domain.com [root@amsdc2-n-s04taw root]# time id userid uid=36923(userid) gid=36923(u_036923) groups=36923(u_036923)
real 0m10.509s user 0m0.030s sys 0m0.090s
********** Route****************
[root@linux]# traceroute transporter02 traceroute to transporter02.domain.com (IP), 30 hops max, 46 byte packets 1 nlamsdc2mp078-hsrp.net-equip.domain.net (IP) 0.000 ms 0.000 ms 0.000ms 2 transporter02.domain.com (IP) 0.000 ms 0.000 ms 0.000 ms
solaris# traceroute transporter02 traceroute to transporter02.domain.com (145.6.246.53), 30 hops max, 40 byte packets 1 transporter02.domain.com (145.6.246.53) 0.462 ms 0.279 ms 0.306 ms
Although I considered that latency involved but still I'm not statisfied, is there any tunable parameter that I can set on linux box to somehow improve the performance?
I also noticed things that I'm not sure if this is default on linux nis bindings:
[root@linux]# pwd /var/yp/binding [root@linux]# ls NONAME.DOMAIN.COM.1 NONAME.DOMAIN.COM.2 ===> why there are two of this on linux?
solaris# cd /var/yp/binding solaris# ls NONAME.DOMAIN.COM xprt.tcp.3 xprt.ticlts.3 xprt.ticotsord.2 xprt.udp.2 xprt.tcp.1 xprt.ticlts.1 xprt.ticots.3 xprt.ticotsord.3 xprt.udp.3 xprt.tcp.2 xprt.ticlts.2 xprt.ticotsord.1 xprt.udp.1 ypbind.pid
Thanks in advance for any feedback.
Things I've tried to tweak:
* put NIS Server IP on /etc/yp.conf * put NIS Server IP on /etc/hosts no positive result.
joseph
On 10/13/07, Steve Rigler srigler@marathonoil.com wrote:
Yes there is and running.
-Steve
Joseph
_______________________________________________
On 10/12/07, joseph blase joseph.mailboxlist@gmail.com wrote:
In my case nscd does make a difference as pointed out earlier. On my CentOS machine,
Without nscd:
real 0m0.116s user 0m0.008s sys 0m0.014s
With nscd:
real 0m0.007s user 0m0.002s sys 0m0.004s
My Solaris box is running nscd:
0.03u 0.01s 0:00.05
Akemi
On Sat, Oct 13, 2007 at 03:45:14AM +0800, joseph blase alleged:
Start with 'strace id userid' to see where it is stalling. Maybe you'll find a bad PTR lookup or something.
You can also determine if the stall is in NIS code with 'ypmatch userid passwd'.
If nscd is running, does killing it make a difference?
Any selinux violations in /var/log/messages?
On 10/13/07, Garrick Staples garrick@usc.edu wrote:
Thanks, seems strace show something use but can't parse it.
[root@linux]# strace -c -e trace=network -T id userid uid=36923(userid) gid=36923(u_036923) groups=36923(u_036923) % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 26.19 0.879992 86 10184 72 bind 23.81 0.800000 200000 4 connect 17.26 0.579985 57 10112 recvfrom 12.50 0.419998 42 10112 sendto 12.20 0.409995 41 10112 setsockopt 8.04 0.269990 27 10116 socket ------ ----------- ----------- --------- --------- ---------------- 100.00 3.359960 50640 72 total [root@linux]# strace -c -T id userid uid=36923(myjtaf) gid=36923(u_036923) groups=36923(u_036923) % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 28.37 5.659654 560 10112 poll 4.36 0.869994 85 10184 72 bind 4.21 0.839992 83 10114 readv 4.06 0.809998 80 10131 7 open 4.06 0.809974 80 10112 setsockopt 4.01 0.800000 200000 4 mprotect 4.01 0.800000 200000 4 brk 4.01 0.800000 200000 4 writev 4.01 0.800000 200000 4 connect 3.91 0.779980 77 10112 sendto 3.51 0.700000 700000 1 write 3.51 0.700000 33333 21 mmap 3.51 0.700000 700000 1 getpid 3.51 0.700000 700000 1 arch_prctl 3.01 0.600000 33333 18 read 3.01 0.600000 75000 8 munmap 2.76 0.549979 54 10116 fcntl 2.66 0.529992 52 10112 ioctl 2.21 0.439998 44 10112 recvfrom 2.01 0.400000 200000 2 lseek 2.01 0.400000 200000 2 uname 1.40 0.279993 28 10116 socket 1.40 0.279977 14 20240 close 0.50 0.100000 7692 13 fstat ------ ----------- ----------- --------- --------- ---------------- 100.00 19.949531 121544 79 total
It seem that bind to something takes too much time.
You can also determine if the stall is in NIS code with 'ypmatch userid passwd'.
Normal here.
If nscd is running, does killing it make a difference?
It worsen it.
Any selinux violations in /var/log/messages?
None, as no selinux enabled.
with trace=bind output, please shed light what's happening in this?
[root@linux root]# strace -e trace=bind -T id userid bind(5, {sa_family=AF_INET, sin_port=htons(682), sin_addr=inet_addr("0.0.0.0")}, 16) = 0 <0.000000> bind(5, {sa_family=AF_INET, sin_port=htons(683), sin_addr=inet_addr("0.0.0.0")}, 16) = 0 <0.000000> bind(5, {sa_family=AF_INET, sin_port=htons(684), sin_addr=inet_addr("0.0.0.0")}, 16) = 0 <0.000000> bind(5, {sa_family=AF_INET, sin_port=htons(685), sin_addr=inet_addr("0.0.0.0")}, 16) = 0 <0.000000> bind(5, {sa_family=AF_INET, sin_port=htons(686), sin_addr=inet_addr("0.0.0.0")}, 16) = 0 <0.000000> bind(5, {sa_family=AF_INET, sin_port=htons(687), sin_addr=inet_addr("0.0.0.0")}, 16) = 0 <0.000000> bind(5, {sa_family=AF_INET, sin_port=htons(688), sin_addr=inet_addr("0.0.0.0")}, 16) = 0 <0.000000> bind(5, {sa_family=AF_INET, sin_port=htons(689), sin_addr=inet_addr("0.0.0.0")}, 16) = 0 <0.000000> bind(5, {sa_family=AF_INET, sin_port=htons(690), sin_addr=inet_addr("0.0.0.0")}, 16) = 0 <0.000000> bind(5, {sa_family=AF_INET, sin_port=htons(691), sin_addr=inet_addr("0.0.0.0")}, 16) = 0 <0.000000>
<<< ---------------Very Long same messages------------------------------------------>>
bind(5, {sa_family=AF_INET, sin_port=htons(672), sin_addr=inet_addr("0.0.0.0")}, 16) = 0 <0.000000> bind(5, {sa_family=AF_INET, sin_port=htons(673), sin_addr=inet_addr("0.0.0.0")}, 16) = -1 EADDRINUSE (Address already in use) <0.000000> bind(5, {sa_family=AF_INET, sin_port=htons(674), sin_addr=inet_addr("0.0.0.0")}, 16) = 0 <0.000000> bind(5, {sa_family=AF_INET, sin_port=htons(675), sin_addr=inet_addr("0.0.0.0")}, 16) = 0 <0.000000> bind(5, {sa_family=AF_INET, sin_port=htons(676), sin_addr=inet_addr("0.0.0.0")}, 16) = 0 <0.000000> bind(5, {sa_family=AF_INET, sin_port=htons(677), sin_addr=inet_addr("0.0.0.0")}, 16) = 0 <0.000000> bind(5, {sa_family=AF_INET, sin_port=htons(678), sin_addr=inet_addr("0.0.0.0")}, 16) = 0 <0.000000> bind(5, {sa_family=AF_INET, sin_port=htons(679), sin_addr=inet_addr("0.0.0.0")}, 16) = 0 <0.000000> bind(5, {sa_family=AF_INET, sin_port=htons(680), sin_addr=inet_addr("0.0.0.0")}, 16) = 0 <0.000000> bind(5, {sa_family=AF_INET, sin_port=htons(681), sin_addr=inet_addr("0.0.0.0")}, 16) = 0 <0.000000> bind(5, {sa_family=AF_INET, sin_port=htons(682), sin_addr=inet_addr("0.0.0.0")}, 16) = 0 <0.000000> bind(5, {sa_family=AF_INET, sin_port=htons(683), sin_addr=inet_addr("0.0.0.0")}, 16) = 0 <0.000000> bind(5, {sa_family=AF_INET, sin_port=htons(684), sin_addr=inet_addr("0.0.0.0")}, 16) = 0 <0.000000> bind(5, {sa_family=AF_INET, sin_port=htons(685), sin_addr=inet_addr("0.0.0.0")}, 16) = 0 <0.000000> bind(5, {sa_family=AF_INET, sin_port=htons(686), sin_addr=inet_addr("0.0.0.0")}, 16) = 0 <0.000000> bind(5, {sa_family=AF_INET, sin_port=htons(687), sin_addr=inet_addr("0.0.0.0")}, 16) = 0 <0.000000> bind(5, {sa_family=AF_INET, sin_port=htons(688), sin_addr=inet_addr("0.0.0.0")}, 16) = 0 <0.000000> bind(5, {sa_family=AF_INET, sin_port=htons(689), sin_addr=inet_addr("0.0.0.0")}, 16) = 0 <0.000000> uid=36923(userid) gid=36923(u_036923) groups=36923(u_036923) Joseph
On Sat, 13 Oct 2007, joseph blase wrote:
-snip-
Maybe this ?
man ypbind
-broken-server lets ypbind accept answers from servers running on an ille- gal port number. This should usually be avoided, but is required by some ypserv(8) versions.
-
Akemi Yagi -
Dag Wieers -
Garrick Staples -
joseph blase -
Steve Rigler