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 ?
--
Sincerely,
William Brown
Software Engineer
Red Hat, Brisbane
No comments:
Post a Comment