The way the code is now (ie, 0.5.6), it should only recompute the
gids mapping if the mtime of /etc/group has changed since the last
update. But if you're running NIS, the mtime of /etc/group shouldn't
be changing. And so the gids mapping should only get computed once.
Is the mtime of /etc/group changing?
I've made some changes to gids:
1. Added support to cache the uid info returned by getpwnam() each
time the gids mapping is recomputed.
2. Added support for setting it to a value of 0 to cause the gids
mapping to be computed initially, but then never updated.
3. Added support for setting it to a value of -1 to cause the gids
mapping to be skipped altogether; it's only of use if you're
restricting credentials based on supplemental groups.
4. Changed the MUNGE_GROUP_PARSE_TIMER from 900 to 3600.
In my limited testing, the uid caching shows a substantial improvement.
If that's still not sufficient, try setting MUNGE_GROUP_PARSE_TIMER in
src/libcommon/munge_defs.h to either 0 or -1; if that works for you,
let me know and I'll make the timer value a longopt.
I've placed a code snapshot in <http://dl.gna.org/munge/alpha/> for you
to test.
-Chris
On Mon, 12/18/06 03:32p EST, Jeff Squyres wrote:
>
> Actually, I was only testing on two back-end nodes (separately, at
> different times) before deploying it on all of them. So I don't
> think it's an overloading problem.
>
> The head node runs the whole gid has map routine in 15-30 seconds --
> the back-end nodes seem to take *much* longer than that (I verified
> this with a standalone C program that essentially duplicates what the
> gid hash map routine does -- looping over getgrent(), etc.). So I
> think that this is some kind of not-related-to-munge configuration
> problem on my part.
>
> I'm trying to track that down now.
>
> (FWIW, I don't think my post made it to the list again -- you got it
> because I did "reply all" and therefore you were CC'ed)
>
>
> On Dec 18, 2006, at 3:25 PM, Chris Dunlap wrote:
>
> > I wonder if part of the problem is with the gids map updating on
> > all of the back-end nodes at the same time, and the NIS service is
> > getting hammered.
> >
> > -Chris
> >
> >
> > On Mon, 12/18/06 03:06p EST, Jeff Squyres wrote:
> >>
> >> - I put some printf's in the code to show that the gid lookup for the
> >> hash map does seem to be the culprit; the getgrent function runs
> >> *much* faster on the head node than my compute nodes (suggesting some
> >> kind of not-related-to-munge configuration problem on my compute
> >> nodes -- I'm investigating).
_______________________________________________
munge-users mailing list
[EMAIL PROTECTED]
https://mail.gna.org/listinfo/munge-users
