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(a)redhat.com>:
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(a)gmail.com> escribió:
>
>>
>> 2009/10/27 Andrey Ivanov <andrey.ivanov(a)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(a)redhat.com
>
https://www.redhat.com/mailman/listinfo/fedora-directory-users
>
--
389 users mailing list
389-users(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-directory-users