Hi Yes, we have 30 different sub-suffixes, each with its own database, that are replicated over 30 differents centers (buildings). The same indexes (shown in a previous post) have been applied to all databases, included userroot, and all databases have been reindexed with those indexes. But that search keeps taking so long time (more than 6 minutes to return about 30000 objects, as said before). Regards. 2009/11/4 Rich Megginson <rmeggins@xxxxxxxxxx>: > 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@xxxxxxxxx> escribió: >> >>> >>> 2009/10/27 Andrey Ivanov <andrey.ivanov@xxxxxxxxxxxxxxxx>: >>> >>>> >>>> 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@xxxxxxxxxx >> https://www.redhat.com/mailman/listinfo/fedora-directory-users >> > > > > -- > 389 users mailing list > 389-users@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > -- 389 users mailing list 389-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-users
