samba - Feb 2015 - performance issue with large group and dbcheck / dc join

Hi everyone,

yesterday I had to debug a failing join on a large domain for a group of 
primary schools with 1000+ desktop and 10k accounts. The domain run 
mostly ok except for some replications issues, however joining a new DC 
just takes eons and so does dbcheck.

After some investigation into dbcheck (4.1.17) and some "human
powered"
valgrind like evalution using pudb, I came to the conclusion that it was 
the computation of the memberof attribute that was to blame. Disabling 
that attribute check in the dbcheck code did solve the issue.

Actually there was a "pupils" group where all new pupils were 
automaticaly added (and which had in fact no real usage). So that was a 
group with about 10k members. Deleting the group resolved the dbcheck 
performance issue and the join at the same time. The dbcheck went for a 
few hours of run to just 6 minutes. I think that thread was experiencing 
a similar issue: https://lists.samba.org/archive/samba/2014-July/182819.html

Doing such large group is probably not a good idea, be it on a samba4 AD 
or on a MS AD. But for people with linux scripting background, it is 
much easier to just add a line in their adduser script that screw up the 
whole thing.

Should I open a bug for that?

Cheers,

Denis
-- 
Denis Cardon
Tranquil IT Systems
Les Espaces Jules Verne, b?timent A
12 avenue Jules Verne
44230 Saint S?bastien sur Loire
tel : +33 (0) 2.40.97.57.55
http://www.tranquil-it-systems.fr

On Wed, Feb 25, 2015 at 10:33:57AM +0100, Denis Cardon
wrote:
> Hi everyone,
> 
> yesterday I had to debug a failing join on a large domain for a
> group of primary schools with 1000+ desktop and 10k accounts. The
> domain run mostly ok except for some replications issues, however
> joining a new DC just takes eons and so does dbcheck.
> 
> After some investigation into dbcheck (4.1.17) and some "human
> powered" valgrind like evalution using pudb, I came to the
> conclusion that it was the computation of the memberof attribute
> that was to blame. Disabling that attribute check in the dbcheck
> code did solve the issue.
> 
> Actually there was a "pupils" group where all new pupils were
> automaticaly added (and which had in fact no real usage). So that
> was a group with about 10k members. Deleting the group resolved the
> dbcheck performance issue and the join at the same time. The dbcheck
> went for a few hours of run to just 6 minutes. I think that thread
> was experiencing a similar issue:
> https://lists.samba.org/archive/samba/2014-July/182819.html
> 
> Doing such large group is probably not a good idea, be it on a
> samba4 AD or on a MS AD. But for people with linux scripting
> background, it is much easier to just add a line in their adduser
> script that screw up the whole thing.
> 
> Should I open a bug for that?
Yes, if it's causing a domain join fail then we need a bug
to track it.

Thanks !