Red Hat Bugzilla – Bug 1523183
search with CoS attribute is getting slower after modifying/adding CosTemplate
Last modified: 2018-04-10 10:24:45 EDT
Created attachment 1364283 [details] sample ldif to reproduce the issue Description of problem: When using Indirect Cos like the following, dn: cn=cosDefinition,dc=test,dc=com objectClass: top objectClass: ldapsubentry objectClass: cossuperdefinition objectClass: cosIndirectDefinition cosAttribute: ou merge-schemes cosAttribute: description merge-schemes cosAttribute: postalCode merge-schemes cn: cosDefinition cosIndirectSpecifier: seeAlso search takes longer than before after cosTemplate entries are added/modified. Version-Release number of selected component (if applicable): 389-ds-base-1.3.6.1-24.el7_4.x86_64 How reproducible: This can be reproduced with attached sample LDIF. Steps to Reproduce: 1. create suffix dc=test,dc=com and import test.ldif (or adjust suffix accordingly) 2. run the following search ldapsearch -D "cn=directory manager" -w password -b dc=test,dc=com uid=user1 => this return the result immediately 3. add new cosTemplcate by the following command ldapmodify -D "cn=directory manager" -w password -a -c -f ou10000.ldif stop ldapmodify after adding about 500 entries by CTRL+C 4. run the same search ldapsearch -D "cn=directory manager" -w password -b dc=test,dc=com uid=user1 => this will take a time than step 2 5. add new cosTemplcate by the following command again ldapmodify -D "cn=directory manager" -w password -a -c -f ou10000.ldif stop ldapmodify after adding around 500 entries by CTRL+C 6. run the same search ldapsearch -D "cn=directory manager" -w password -b dc=test,dc=com uid=user1 => this will take a time than step 2 and 4 7. add additional Cos Identifier attribute ldapmodify -D "cn=directory manager" -w password -a -f addCosIdentifier.ldif 8. run the same search ldapsearch -D "cn=directory manager" -w password -b dc=test,dc=com uid=user1 => this will take too time than before (Cos works as expected though) 9. restart server and do the same search => this returns entry immediately Actual results: search takes longer time than before Expected results: search returns result soon Additional info: This happen after applying 389-ds-base-1.3.6.1-24.el7_4.x86_64. But this does not happen with 389-ds-base-1.3.6.1-23.el7_4.x86_64
Upstream ticket: https://pagure.io/389-ds-base/issue/49495
Created attachment 1366205 [details] Resolve mm issue with vattr This patch resolves the issue. This has been resolved upstream on affected branches.
patch was confirmed good, making this bz 1523183 a RHEL-7.4.z candidate for the sf customer case number 01987672 to be reviewed tomorrow with dev and qe.
Build tested: 389-ds-base-1.3.7.5-14.el7.x86_64 CoS test suite from acceptance tests passes 100% without a crash. CoS scale stress test passes: ===================================================================== test session starts ===================================================================== platform linux -- Python 3.6.3, pytest-3.3.2, py-1.5.2, pluggy-0.6.0 -- /opt/rh/rh-python36/root/usr/bin/python3 cachedir: .cache metadata: {'Python': '3.6.3', 'Platform': 'Linux-3.10.0-837.el7.x86_64-x86_64-with-redhat-7.5-Maipo', 'Packages': {'pytest': '3.3.2', 'py': '1.5.2', 'pluggy': '0.6.0'}, 'Plugins': {'metadata': '1.5.1', 'html': '1.16.1'}} 389-ds-base: 1.3.7.5-14.el7 nss: 3.34.0-4.el7 nspr: 4.17.0-1.el7 openldap: 2.4.44-12.el7 svrcore: 4.1.3-2.el7 rootdir: /export/tests, inifile: plugins: metadata-1.5.1, html-1.16.1 collected 1 item stress/cos/cos_scale_template_test.py::test_indirect_template_scale PASSED [100%] ------------------------------------------------ generated xml file: /mnt/tests/rhds/tests/upstream/report.xml ------------------------------------------------ ----------------------------------------------- generated html file: /mnt/tests/rhds/tests/upstream/report.html ----------------------------------------------- ================================================================== 1 passed in 62.78 seconds ==================================================================
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://access.redhat.com/errata/RHBA-2018:0811