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
Attachment:
signature.asc
Description: This is a digitally signed message part
-- 389 users mailing list 389-users@%(host_name)s http://lists.fedoraproject.org/admin/lists/389-users@xxxxxxxxxxxxxxxxxxxxxxx
