[389-users] Query blocking server

[Rich Megginson]

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>