Hi,
Thank you for your answer!
Here the result of the rpm command:
389-ds-base-1.3.3.1-23.el7_1.x86_64
389-ds-base-1.3.4.0-19.el7.x86_64
389-ds-base-libs-1.3.4.0-19.el7.x86_64
389-ds-base-devel-1.3.4.0-19.el7.x86_64
The ldapsearch results are enclosed. You have to take into account that
this is not yet in production - will be very soon and that's why I'm a
little bit concerned about the performance :)
I was just thinking how well indexing works at all for searches that
contain nsrole-attribute conditions, since nsrole is a dynamic computed
attribute - we are using roles a lot and searches may include logical
combinations of many roles.
Regards,
Petteri
On 25.11.2015 23:20, William Brown wrote:
On Wed, 2015-11-25 at 09:35 +0200, Petteri Jekunen wrote:
> Hi,
>
> Is it just ordinary behavior with 389 DS that search results may take
> a
> very loong time just after starting the server when there are no
> entries
> in the cache yet?
> And when the cache is fully saturated (enough cache configured for
> all
> the entries) results become dramatically down - for instance from 4
> minutes to 4 seconds.
>
> If this this is so, is there anything that could be done to fill in
> the
> cache automatically after startup?
>
> We have some 60 000 entries, RHEL 7.1, 389-Directory/1.3.3.1
> B2015.267.1737 on VMWare.
> We have quite a heavy use of roles, and this seems to be a
> significant
> issue especially with them - or at least with them.
> We have used the Sun DSEE previously and are quite new to 389 DS. The
> technology seems very similar although.
>
> Thanks a lot in advance!
Can you post:
rpm -qa | grep 389-ds-base
for the rpm version
As well, can we see:
ldapsearch -b cn=monitor,cn=ldbm database,cn=plugins,cn=config -s base
ldapsearch -b cn=userRoot,cn=ldbm database,cn=plugins,cn=config -s base
ldapsearch -b cn=monitor,cn=userRoot,cn=ldbm
database,cn=plugins,cn=config -s base
This will show what the cache hit rates and sizing are.
You may find that the issue is a lack of key indexes, and that once the
cache is primed that is masking the issue. Perhaps look in the access
log for notes=U ?
--
389 users mailing list
389-users@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org