On Thu, 2015-11-26 at 22:30 +0200, Petteri Jekunen wrote: > 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 :) > That's a very reasonable concern to have, and good to understand. Remember, slapd tends to run for months at a time, so this is an extraordinary circumstance. If you have a load balancer setup, than you can always takes Rich's advice on the "cold" node before you re-insert to the load balancer pool. > 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. Provided that the attributes you use the condition are indexed, it should be okay. However, it depends what you are doing. I found previously that things like memberOf were better than roles, because you can filter very effectively on memeberOf attributes on an object, rather than have to use nsRole. But it really depends on your object and schema design that you are choosing to use. Did you check for un-indexed searchs in the logs as well? Can you post the cache sizes that I asked for as well? See below. > > > > 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
