[389-users] Re: Slow search results until cache populated

[Petteri Jekunen]

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/[e-mail]
>