Bug 1044135
| Summary: | [RFE] make connection buffer size adjustable | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Nathan Kinder <nkinder> |
| Component: | 389-ds-base | Assignee: | Rich Megginson <rmeggins> |
| Status: | CLOSED ERRATA | QA Contact: | Viktor Ashirov <vashirov> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | low | ||
| Version: | 7.0 | CC: | amsharma, nhosoi, rmeggins, spichugi |
| Target Milestone: | rc | Keywords: | FutureFeature |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | 389-ds-base-1.3.3.1-1.el7 | Doc Type: | Enhancement |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2015-03-05 09:29:39 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Nathan Kinder
2013-12-17 21:15:28 UTC
Note that this is not something that we will be documenting or exposing to customers at this time. * using ldapmodify, set nsslapd-connection-buffer in cn=config to 2 - confirm with ldapsearch that the value is set to 2 - confirm that ldapsearch works and doesn't cause any errors or crashing * using ldapmodify, set nsslapd-connection-buffer in cn=config to 0 - confirm with ldapsearch that the value is set to 0 - confirm that ldapsearch works and doesn't cause any errors or crashing * using ldapmodify, set nsslapd-connection-buffer in cn=config to 1 - confirm with ldapsearch that the value is set to 1 - confirm that ldapsearch works and doesn't cause any errors or crashing * using ldapmodify, set nsslapd-connection-buffer in cn=config to 3 - confirm that server returns Operations Error - confirm with ldapsearch that the value was not changed * using ldapmodify, set nsslapd-connection-buffer in cn=config to -1 - confirm that server returns Operations Error - confirm with ldapsearch that the value was not changed * using ldapmodify, set nsslapd-connection-buffer in cn=config to "a" - confirm that server returns Operations Error - confirm with ldapsearch that the value was not changed (In reply to Rich Megginson from comment #3) > Note that this is not something that we will be documenting or exposing to > customers at this time. > > * using ldapmodify, set nsslapd-connection-buffer in cn=config to 2 > - confirm with ldapsearch that the value is set to 2 > - confirm that ldapsearch works and doesn't cause any errors or crashing > > * using ldapmodify, set nsslapd-connection-buffer in cn=config to 0 > - confirm with ldapsearch that the value is set to 0 > - confirm that ldapsearch works and doesn't cause any errors or crashing > > * using ldapmodify, set nsslapd-connection-buffer in cn=config to 1 > - confirm with ldapsearch that the value is set to 1 > - confirm that ldapsearch works and doesn't cause any errors or crashing > What differences should we see for above 3 values(0,1 and 2)? Does it affect performance of large ldap searches? Should we set one of this value in TET to increase the response time? > * using ldapmodify, set nsslapd-connection-buffer in cn=config to 3 > - confirm that server returns Operations Error > - confirm with ldapsearch that the value was not changed > > * using ldapmodify, set nsslapd-connection-buffer in cn=config to -1 > - confirm that server returns Operations Error > - confirm with ldapsearch that the value was not changed > > * using ldapmodify, set nsslapd-connection-buffer in cn=config to "a" > - confirm that server returns Operations Error > - confirm with ldapsearch that the value was not changed (In reply to Sankar Ramalingam from comment #4) > (In reply to Rich Megginson from comment #3) > > Note that this is not something that we will be documenting or exposing to > > customers at this time. > > > > * using ldapmodify, set nsslapd-connection-buffer in cn=config to 2 > > - confirm with ldapsearch that the value is set to 2 > > - confirm that ldapsearch works and doesn't cause any errors or crashing > > > > * using ldapmodify, set nsslapd-connection-buffer in cn=config to 0 > > - confirm with ldapsearch that the value is set to 0 > > - confirm that ldapsearch works and doesn't cause any errors or crashing > > > > * using ldapmodify, set nsslapd-connection-buffer in cn=config to 1 > > - confirm with ldapsearch that the value is set to 1 > > - confirm that ldapsearch works and doesn't cause any errors or crashing > > > What differences should we see for above 3 values(0,1 and 2)? You shouldn't see any differences. > Does it affect performance of large ldap searches? Not exactly, and it is very difficult to measure. > Should we set one of this value in TET to increase the response time? Not sure what you mean. The intention of nsslapd-connection-buffer is for use in future performance investigation by development. It is not intended (at this time) for users to change the setting at all. > > * using ldapmodify, set nsslapd-connection-buffer in cn=config to 3 > > - confirm that server returns Operations Error > > - confirm with ldapsearch that the value was not changed > > > > * using ldapmodify, set nsslapd-connection-buffer in cn=config to -1 > > - confirm that server returns Operations Error > > - confirm with ldapsearch that the value was not changed > > > > * using ldapmodify, set nsslapd-connection-buffer in cn=config to "a" > > - confirm that server returns Operations Error > > - confirm with ldapsearch that the value was not changed ldapmodify -D "cn=directory manager" -w Secret123 -p 389 -h localhost << EOF dn: cn=config changetype: modify replace: nsslapd-connection-buffer nsslapd-connection-buffer: 2 EOF [root@dhcp201-126 ~]# ldapsearch -D "cn=directory manager" -w Secret123 -p 389 -h localhost -b "cn=config" | grep nsslapd-connection-buffer nsslapd-connection-buffer: 2 [root@dhcp201-126 ~]# ldapmodify -D "cn=directory manager" -w Secret123 -p 389 -h localhost << EOF > dn: cn=config > changetype: modify > replace: nsslapd-connection-buffer > nsslapd-connection-buffer: 0 > EOF modifying entry "cn=config" [root@dhcp201-126 ~]# ldapsearch -D "cn=directory manager" -w Secret123 -p 389 -h localhost -b "cn=config" | grep nsslapd-connection-buffer nsslapd-connection-buffer: 0 [root@dhcp201-126 ~]# [root@dhcp201-126 ~]# ldapmodify -D "cn=directory manager" -w Secret123 -p 389 -h localhost << EOF > dn: cn=config > changetype: modify > replace: nsslapd-connection-buffer > nsslapd-connection-buffer: 1 > EOF modifying entry "cn=config" [root@dhcp201-126 ~]# ldapmodify -D "cn=directory manager" -w Secret123 -p 389 -h localhost << EOF > dn: cn=config > changetype: modify > replace: nsslapd-connection-buffer > nsslapd-connection-buffer: 3 > EOF modifying entry "cn=config" ldap_modify: Operations error (1) additional info: nsslapd-connection-buffer: invalid value "3". Valid values are "0", "1", or "2". [root@dhcp201-126 ~]# ldapsearch -D "cn=directory manager" -w Secret123 -p 389 -h localhost -b "cn=config" | grep nsslapd-connection-buffer nsslapd-connection-buffer: 1 [root@dhcp201-126 ~]# ldapmodify -D "cn=directory manager" -w Secret123 -p 389 -h localhost << EOF dn: cn=config changetype: modify replace: nsslapd-connection-buffer nsslapd-connection-buffer: -1 EOF modifying entry "cn=config" ldap_modify: Operations error (1) additional info: nsslapd-connection-buffer: invalid value "-1". Valid values are "0", "1", or "2". [root@dhcp201-126 ~]# ldapsearch -D "cn=directory manager" -w Secret123 -p 389 -h localhost -b "cn=config" | grep nsslapd-connection-buffer nsslapd-connection-buffer: 1 [root@dhcp201-126 ~]# ldapmodify -D "cn=directory manager" -w Secret123 -p 389 -h localhost << EOF dn: cn=config changetype: modify replace: nsslapd-connection-buffer nsslapd-connection-buffer: a EOF modifying entry "cn=config" ldap_modify: Operations error (1) additional info: nsslapd-connection-buffer: invalid value "a". Valid values are "0", "1", or "2". Hence VERIFIED. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHSA-2015-0416.html |