Juan Asensio S?nchez wrote: > Hi > > I am already having poor performance when running this query. Any more > ideas to try? Could be related due to the data is across almost 30 > different databases? > Could be. What do you mean by "30 different databases"? Chaining? Sub-suffixes? Can you provide more details? Note that index configuration is specific to a database - so if you have sub-suffixes with their own databases, you will have to make sure your attributes are indexed correctly in all of those databases. > Regards. > > > El d?a 28 de octubre de 2009 08:58, Juan Asensio S?nchez > <okelet at gmail.com> escribi?: > >> 2009/10/27 Andrey Ivanov <andrey.ivanov at polytechnique.fr>: >> >>> 6 minutes for 25000 entries is obviously too much. On our server (HP of two >>> years old ang 2Go of memory) 8300 entries are returned in 0.77 seconds (the >>> filter is almost like yours - "(&(uid=*)(objectClass=inetOrgPerson))"). >>> There is certainly some problem either with the disk access or with the >>> memory sizing or with the indexed searches in your configuration... Do you >>> have the PRESENCE index on uid? >>> >>> >> For one moment I thought UID was not indexed, but I checked twice it >> is indexed. These are all the attributes indexed in out databases: >> >> aci: >> system: true >> type: [pres] >> >> entryDN: >> system: true >> type: [eq] >> >> nscpEntryDN: >> system: true >> type: [eq] >> >> nsds5ReplConflict: >> system: true >> type: [eq, pres] >> >> nsUniqueId: >> system: true >> type: [eq] >> >> numSubordinates: >> system: true >> type: [pres] >> >> objectClass: >> system: true >> type: [eq, pres] >> >> parentID: >> system: true >> type: [eq] >> >> cn: >> system: false >> type: [pres, eq, sub] >> >> displayName: >> system: false >> type: [pres, eq, sub] >> >> gidNumber: >> system: false >> type: [pres, eq] >> >> givenName: >> system: false >> type: [pres, eq, sub] >> >> mail: >> system: false >> type: [pres, eq, sub] >> >> mailAlternateAddress: >> system: false >> type: [pres, eq, sub] >> >> memberOf: >> system: false >> type: [eq] >> >> memberUid: >> system: false >> type: [eq] >> >> ntUniqueId: >> system: false >> type: [eq] >> >> ntUserDomainId: >> system: false >> type: [eq] >> >> o: >> system: false >> type: [pres, eq, sub] >> >> ou: >> system: false >> type: [pres, eq, sub] >> >> sambaDomainName: >> system: false >> type: [pres, eq] >> >> sambaGroupType: >> system: false >> type: [pres, eq] >> >> sambaPrimaryGroupSID: >> system: false >> type: [pres, eq] >> >> sambaSID: >> system: false >> type: [pres, eq] >> >> sambaSIDList: >> system: false >> type: [pres, eq] >> >> seeAlso: >> system: false >> type: [pres, eq, sub] >> >> sn: >> system: false >> type: [pres, eq, sub] >> >> telephoneNumber: >> system: false >> type: [pres, eq, sub] >> >> uid: >> system: false >> type: [pres, eq, sub] >> >> uidNumber: >> system: false >> type: [pres, eq] >> >> uniqueMember: >> system: false >> type: [pres, eq, sub] >> >> (This is part of a file we use to define database indexes, adding or >> removing necessary attributes to the default indexes). >> >> Regards. >> >> > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.fedoraproject.org/pipermail/389-users/attachments/20091104/a325cb46/attachment.bin
