[389-users] Query blocking server
Rich Megginson
rmeggins at redhat.com
Wed Nov 4 16:23:46 UTC 2009
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://listman.redhat.com/archives/fedora-directory-users/attachments/20091104/a325cb46/attachment.bin>
More information about the Fedora-directory-users
mailing list