Sparc DS5.2p4 NFS netgroup performance problem

Question

We recently setup our NFS server as an LDAP client. We use netgroups to provide a list of clients for each shared FS. Since moving to LDAP (from NIS+) the performance has been abysmal. I've created all the indices, VLV and regular, per the Sun instructions.
I've always known that netgroups in LDAP was poorly handled, from a client point of view. I even made my own access mechanism for users because netgroups for user access was slow. Today, I did some searching on Sunsolve and found Bug ID 4734259. Here's an excerpt:
The comment about these lookups being done in clusters may have
been true back in the old days.  But now the in-kernel NFS code
asks mountd questions like this all the time rather than only
at mount time.
Bug4176752 is (partly) about the fact that nscd does not cache netgroups.
Now with LDAP in the nsswitch.conf, caching these things becomes
more important.  Here we find mountd has a cache, but it keeps it
for a very short period.  That period was long enough initially,
but now the the kernel NFS code checks this info at access time
instead of mount time, the cache timeout should be longer, if not configurable
[email protected] 2003-03-14Sun has known about this for TWO YEARS and has not addressed the problem!!! At the same time, they're pushing LDAP as the be-all naming service. To put this in perspective, our NIS+ server was running on a V120. The LDAP server is running on a 3800 (4x750Mhz) and it gets routinely pegged with the slapd processing taking 70% of the CPU.
Also, one of our NFS servers is under cluster control and it doesn't even seem to understand the LDAP-based netgroups. We had to modify nsswitch.conf to check NIS+.
Has anyone else encountered performance issues with netgroups in LDAP and NFS?
In the near future, I'll be rebuilding the VLV indices. I'm hoping that will correct our problems.
Thanks,
Roger S.

Answer 1

Thanks.
I think it may be one of the issue. But looking at ldd command output I think much more libarary getting called for a simple command in Solaris 10 (production env) then to the Solaris 9 (Test env).
Production Server:
Prompt> ldd /usr/bin/ls
libsec.so.1 => /lib/libsec.so.1
libc.so.1 => /lib/libc.so.1
libavl.so.1 => /lib/libavl.so.1
libm.so.2 => /lib/libm.so.2
/platform/SUNW,Sun-Fire-T200/lib/libc_psr.so.1
Test Server:
prompt> ldd /usr/bin/ls
libc.so.1 => /usr/lib/libc.so.1
libdl.so.1 => /usr/lib/libdl.so.1
/usr/platform/SUNW,Sun-Fire-V440/lib/libc_psr.so.1
In solaris 10, I can see two library has been added to call ls command itself.
I have done truss on the program (In my original post) and observed that the times is taking after the system call fork abd it returns from it. And at the sample test environment does not take time.
Does this mean Solaris 10 (production env) trying to do something extra then test environment while forking the child process?
Regards,
Aminul Haque