[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: (ITS#4600) slap_mods_check duplicate check is slow with large number of entries



--nextPart1736642.B41FAaz6ol
Content-Type: text/plain;
  charset="iso-8859-6"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Wednesday 28 June 2006 11:27, nick@sqrt.co.uk wrote:
> Full_Name: Nick Burrett
> Version: 2.3.24
> OS:
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (216.239.33.25)
>
>
> I'm using sync-replication and have been wondering why the client-side
> process is staying at 100% CPU use for several hours with the
> synchronisation apparently stalling.
>
> I have a group with 495000 entries, which is taking a very long time to
> sync. Running through a debugger, I find it's getting held-up by this:
>
> modify.c/slapd_mods_check/line 745
>
> /* check for duplicates, but ignore Deletes.  */
> for ( i =3D 1; i < nvals ; i++ ) {
>    /* test asserted values against themselves */
>    for( j =3D 0; j < i; j++ ) {
>       rc =3D ordered_value_match( &match, ml->sml_desc, mr,
>       ...
>    }
> }
>
> So with 'nvals =3D=3D 495000', you can imagine this will take a long time=
 to
> complete.  Typically here, the value of 'nvals' can be 12000 at present a=
nd
> ever growing for one of our group memberships.

This sounds very much like you have not indexed the relevant attributes. If=
=20
so, this is not a bug, but a configuration error. IIRC the admin guide does=
=20
recommend indexing the attributes used by sync-repl (entryCSN, maybe=20
entryUUID as well).

Regards,
Buchan

=2D-=20
Buchan Milne
ISP Systems Specialist
B.Eng,RHCE(803004789010797),LPIC-2(LPI000074592)

--nextPart1736642.B41FAaz6ol
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQBEo9QNrJK6UGDSBKcRAuQxAKDDW01gIEtkD2oNs83faWdYcPTzOwCfTXiV
x/Cc1GIkqWs4a73a4VxUy9Y=
=unjc
-----END PGP SIGNATURE-----

--nextPart1736642.B41FAaz6ol--