Mailing-List: contact users-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@directory.apache.org
Received-SPF: pass (nike.apache.org: local policy)
From: <Carlo.Accorsi@ibs-ag.com>
To: <users@directory.apache.org>
Date: Wed, 10 Oct 2012 04:55:55 +0200
Subject: build monday from trunk very slow for ldif import
Thread-Topic: build monday from trunk very slow for ldif import
Thread-Index: Ac2mkTk1Ra78+E9+QOiVug530Q/hhQ==
Message-ID: <2BE7E81B77921F43A6A273C2DF2FA6A43CCCA9A467@IBSMBX.ibs-ag.com>
Accept-Language: en-US, de-DE
Content-Language: en-US
acceptlanguage: en-US, de-DE
Content-Type: multipart/alternative;
	boundary="_000_2BE7E81B77921F43A6A273C2DF2FA6A43CCCA9A467IBSMBXibsagco_"
MIME-Version: 1.0

--_000_2BE7E81B77921F43A6A273C2DF2FA6A43CCCA9A467IBSMBXibsagco_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi, I'm still trying finish the testing of all the Password policy work Kar=
in did over the weekend but I have another issue that's come up.  Ldif impo=
rts are extremely slow.

During our testing, we often delete the entire partition directory to start=
 fresh. When the server starts, it lays down the partition and .db files as=
 defined config.ldif.

Anyway, we used to import (via studio) an ldif file with 80k entries and it=
 would load about 90 entries per second.  That was great!
With this build it's going at about 4-5 entries per second.

We noticed is that previously, the partition .db files would not change (on=
 disk) until after the ldif import was complete.
Then when we stopped the server, it was like the entire import got flushed =
to the disk at once. The files would go from 20K to 400MB.
With this build, it seems to be updating the files as it goes. Could this b=
e the reason?

Also, this is the first build I noticed the .lg files in the partition dire=
ctory. I think they're there for journaling but don't know if that's an opt=
ion something new?

We removed all the password policy Attributes from my ldif file thinking th=
at was slowing it down but it's essentially the same performance.
Below is my partition and all the indexes are set like the one I included. =
Any changes that would affect this in the last few weeks.  Anyone else seei=
ng this? Thanks!

dn: ads-partitionId=3Dcpro,ou=3Dpartitions,ads-directoryServiceId=3Ddefault=
,ou=3Dconfig
objectclass: top
objectClass: ads-base
objectclass: ads-partition
objectclass: ads-jdbmPartition
ads-indexes: apacheRdn
ads-indexes: apacheSubLevel
ads-indexes: apachePresence
ads-indexes: apacheOneLevel
ads-indexes: apacheOneAlias
ads-indexes: apacheSubAlias
ads-indexes: apacheAlias
ads-indexes: entryCSN
ads-indexes: krb5PrincipalName
ads-indexes: objectClass
ads-indexes: ou
ads-indexes: uid
ads-indexes: employeeNumber
ads-indexes: displayName
ads-indexes: cn
ads-indexes: mail
ads-indexes: roomNumber
ads-indexes: pwdPolicySubEntry
ads-indexes: member
ads-indexes: description
ads-indexes: givenName
ads-indexes: sn
ads-indexes: administrativeRole
ads-partitionSuffix: o=3Dcpro
ads-jdbmpartitionoptimizerenabled: TRUE
ads-partitioncachesize: 100
ads-partitionsynconwrite: TRUE
ads-partitionid: cpro
ads-enabled: TRUE

#index example, they're all like this..HasReverse=3DFALSE
dn: ads-indexAttributeId=3Duid,ou=3Dindexes,ads-partitionId=3Dcpro,ou=3Dpar=
titions,ads-directoryServiceId=3Ddefault,ou=3Dconfig
ads-indexattributeid: uid
ads-indexHasReverse: FALSE
ads-indexcachesize: 100
objectclass: ads-index
objectclass: ads-jdbmIndex
objectclass: ads-base
objectclass: top
ads-enabled: TRUE

--_000_2BE7E81B77921F43A6A273C2DF2FA6A43CCCA9A467IBSMBXibsagco_--