[389-users] Query blocking server

[Juan Asensio Sánchez]

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 at 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 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
>>
>
>
>
> --
> 389 users mailing list
> 389-users at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>
>