Hi,
I noticed a warning from error logs that userRoot cache settings were too small compared to db size.
I tuned cache values based on this article: https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/...
Based on log report, I used following values:
Entry cache: nsslapd-cachememsize: 268435456 (256MB)
DB cache: nsslapd-dbcachesize: 268435456 (256MB)
After this, my second LDAP server gives the following errors: acl__TestRights - cache overflown
Some of the queries fails. For example some of the sudoers entries don't work.
Questions:
1. I changed values using Console. But for the second LDAP server I was not able to save new nsslapd-dbcachesize value, because Save button was greyed out. I changed value using ldapmodify. But is there a reason why Save button is disabled?
2. Do my values make sense in general? Default values were only 10MB and wondering why is that? I have currently 2GB RAM for directory servers and DBs are relatively small. Log reports userRoot size as 180MB. RAM usage is fine, plenty of free memory.
-Vesa
- I changed values using Console. But for the second LDAP server I was
not able to save new nsslapd-dbcachesize value, because Save button was greyed out. I changed value using ldapmodify. But is there a reason why Save button is disabled?
I figured out that Save button is greyed out if value is incorrect (e.g. too big). So it works as it should.
Anyways, I still get "acl__TestRights - cache overflow" error from my second LDAP server which is more heavily loaded. It puzzles me because I only have like less than 10 ACIs in root suffix or in OU levels.
I found only a few references by googling. Like this old bug report: https://bugzilla.redhat.com/show_bug.cgi?id=918702 But I couldn't find nsslapd-aclpb-max-selected-acls attribute. Do I need to add it and what is default value?
Here are my versions (latest EPEL 6 stable):
389-console-1.1.7-1.el6.noarch 389-admin-console-1.1.8-1.el6.noarch 389-admin-console-doc-1.1.8-1.el6.noarch 389-ds-base-libs-1.2.11.25-1.el6.x86_64 389-ds-console-doc-1.2.6-1.el6.noarch 389-ds-base-1.2.11.25-1.el6.x86_64 389-ds-console-1.2.6-1.el6.noarch 389-ds-1.2.2-1.el6.noarch 389-dsgw-1.1.10-1.el6.x86_64 389-adminutil-1.1.15-1.el6.x86_64 389-admin-1.1.29-1.el6.x86_64
This issue appeared when I upgraded 389 packages via normal yum updates from 1.2.11.15.
-Vesa
Hi,
the message is not related to the dbcache, it is about cached aci evaluations and there is a default value of 200. You can increase this by setting the attribute nsslapd-aclpb-max-selected-acls in cn=ACL Plugin,cn=plugins,cn=config and restart the server. There is also a ticket for this: https://fedorahosted.org/389/ticket/342 but the fix only fixes one of two occurrencies of the error message and I 'm not sure if it is in your version.
Regards, Ludwig
On 11/28/2013 08:48 AM, Vesa Alho wrote:
- I changed values using Console. But for the second LDAP server I was
not able to save new nsslapd-dbcachesize value, because Save button was greyed out. I changed value using ldapmodify. But is there a reason why Save button is disabled?
I figured out that Save button is greyed out if value is incorrect (e.g. too big). So it works as it should.
Anyways, I still get "acl__TestRights - cache overflow" error from my second LDAP server which is more heavily loaded. It puzzles me because I only have like less than 10 ACIs in root suffix or in OU levels.
I found only a few references by googling. Like this old bug report: https://bugzilla.redhat.com/show_bug.cgi?id=918702 But I couldn't find nsslapd-aclpb-max-selected-acls attribute. Do I need to add it and what is default value?
Here are my versions (latest EPEL 6 stable):
389-console-1.1.7-1.el6.noarch 389-admin-console-1.1.8-1.el6.noarch 389-admin-console-doc-1.1.8-1.el6.noarch 389-ds-base-libs-1.2.11.25-1.el6.x86_64 389-ds-console-doc-1.2.6-1.el6.noarch 389-ds-base-1.2.11.25-1.el6.x86_64 389-ds-console-1.2.6-1.el6.noarch 389-ds-1.2.2-1.el6.noarch 389-dsgw-1.1.10-1.el6.x86_64 389-adminutil-1.1.15-1.el6.x86_64 389-admin-1.1.29-1.el6.x86_64
This issue appeared when I upgraded 389 packages via normal yum updates from 1.2.11.15.
-Vesa
389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
389-users@lists.fedoraproject.org
-
Ludwig Krispenz -
Vesa Alho