I read where it was recommended (I think for Oracle RAC) to enable the following option:
nis.group_update.enable
The man page says this enables a local cache of the group data.
Are calls to the NIS (ypbind) slow in DOT?
I'm running 6.4.4R1
Thanks
-Rob
I read where it was recommended (I think for Oracle RAC) to enable the following option:
nis.group_update.enable
The man page says this enables a local cache of the group data.
Are calls to the NIS (ypbind) slow in DOT?
I'm running 6.4.4R1
The problem is that NIS provides group maps keyed by group name and by group number (gid). It does not, however, provide a map that is keyed by user that lists all the groups that the user belongs to. But this group list is what a filer needs whenever a user logs in to CIFS (to map windows credentials to Unix credentials)
In order to discover which groups a user belongs to, the filer must use NIS to fetch each group entry and see if the user is listed in it. If you have a very long group map, then every time a user logs in to CIFS the filer must fetch each group entry, with a separate NIS transaction for each one.
By caching the group map, the filer can get the user's group list without NIS. Who knows, the cache may even be organized as group lists keyed by user name.
This is not a problem peculiar to netapps. All Unix systems that use NIS have to linearly scan the entire group map every time a user logs in, to find the user's groups.
If you are not using CIFS then you don't have a problem. NFS does not cause the netapp to scan the group map because each NFS packet contains the user's uid, gid, and group list. The NFS client obtains this information once when the user logs in. I also wouldn't worry about it if your group map is not large.
Anecdote alert:
A few years back one of our NIS servers started chewing up tons of CPU. I traced it and discovered that it was almost 100% sequential scans of our very large group map (almost 700 groups). It turned out that most of these scans were coming from the same machine, which was a busy web server. We had a CGI program run via suexec (which runs the CGI as a particular user). Suexec sets the group list for the user, which requires a linear scan of the NIS group map. So every time this CGI was hit (constantly) the web server was shooting almost 700 NIS requests at the NIS server.
On our netapps and web servers we are now using local /etc/group files updated periodically by cron jobs that copy the NIS map to the local file -- much much better.
Steve Losen scl@virginia.edu phone: 434-924-0640
University of Virginia ITC Unix Support
scl@sasha.acc.virginia.edu (Steve Losen) writes:
[...]
This is not a problem peculiar to netapps. All Unix systems that use NIS have to linearly scan the entire group map every time a user logs in, to find the user's groups.
Or find some way of optimisising things by using a user -> groups map; for example Solaris' netid.byname map combined with the setting NETID_AUTHORITATIVE=TRUE in /etc/default/nss.
And of course, "logs in" includes things like starting a job / crontab for the user, or running a process specifed in a user's .forward file.
On Thu, Mar 03, 2005 at 06:31:48PM -0500, Steve Losen wrote:
The problem is that NIS provides group maps keyed by group name and by group number (gid). It does not, however, provide a map that is keyed by user that lists all the groups that the user belongs to.
'Modern' systems provide the netid.byname map, which among other things contains a mapping between uids to the list of gids.