Re: Weird problem -- seeking insight

[Frank Swasey <Frank.Swasey@uvm.edu>]

Quanah and Howard (et al),
  Thanks for the replies and the help.

  I'll respond to specific items below, but wanted to state up front
that the help is very much appreciated and we think we stumbled across
the solution this morning.  We instituted measurements of the number of
operations and threads running on our ldap servers (using rrdtool) last
night ... results are available at http://mouse.uvm.edu/ldapstats ...

  Anyway, we discovered that the nightly Legato backups were being
kicked off at 2:30am and moved that to 3:30am (to get it away from the
nightly ldap update (via modify) which normally kicks off around 2:27).
The measurements captured a load of approximately 100 operations/second
(spread across bleep, blorp, and penguinx) while the backup was running.
That load (hitting the memberUid index) while ldapmodify was trying to
add/delete values in our huge group caused everything to melt.

On Tue, 20 Jan 2004 at 4:52pm, Quanah Gibson-Mount wrote:

> This really isn't what I do... ;) I simply stop the master and take a
> snapshot of the DB every night, and store it in case I need it. ;)  We
> don't have any major group set up in the way you are talking about, it
> sounds interesting...

Ah, I thought you did a full re-load (via slapcat) of your database
every night.  Sorry, obviously my misunderstanding.

We are using our own versions of the posixAccount and posixGroup
objectClasses to replace the /etc/passwd and /etc/group files.  This
group is simply the default group that all users get stuck in (similar
to staff on an AIX system) instead of every user having their own group
(as the Linux distributions I'm familiar with do).

It's not actually used for mail delivery ... except procmail seems to
like to go find all the groups the user is a member of (or at least
something is doing that regularly -- I have to admit I don't fully
understand the software that is beating on my servers).

On Tue, 20 Jan 2004 at 6:35pm, Howard Chu wrote:

> > - Am I correct about the complete deletion and recreation of the index
> > entries for that entry?
>
> Unfortunately, yes.

Is there a plan to change that?

> > - I think it's fairly obvious that a single group with 40000 members is
>
> There's no good workarounds here. To avoid the index bottleneck, you can turn
> off indexing of the memberUid attribute. If you have a large number of groups
> though, then your searches for (&(objectclass=posixGroup)(memberUid=foo))
> will suffer unless you have other means to narrow the candidates down.

That search is the one that is done, and it never has any other
qualifiers that I see in the logs, so I definately cannot get rid of the
index.

-- 
Frank Swasey                    | http://www.uvm.edu/~fcs
Systems Programmer              | Always remember: You are UNIQUE,
University of Vermont           |    just like everyone else.
                    === God Bless Us All ===