[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--