Description of problem: When processing a great deal of individual changes triggered from the memberof plugin in realtime, schema compat is capable of a sort of storm situation which can consume all available memory to the point of exhaustion. Version-Release number of selected component (if applicable): slapi-nis-0.28-1.fc15.x86_64 How reproducible: 100% Steps to Reproduce: 0. Start with a vanilla FreeIPA Server Install 1. For performance reasons, I find its best to disable schema compat for the import. 2. Import the attached ldif to populate the Directory or run the attached scripted commands to populate the Directory. (This will take 'a long time') 3. Delete the sudorule named admins: ipa sudorule-del admins 4. Run various ldap / freeipa commands: ipa host-find, ldapsearch etc, Notice the huge performance hit. Actual results: Substantial Memory usage and intense usage of slapd process causes serious performance hit. Expected results: Release previously stored values when computing new schema compat modifications and don't consume all available memory. Optimized performance during memberof updates. Additional info:
Created attachment 550537 [details] Ldif for complete test directory
Created attachment 550538 [details] Scripts to populate Test FreeIPA Directory As an alternative to importing the previously attached ldif, you should be able to use the included batch scripts to fully populate the test FreeIPA database.
0.31 and later fix some memory leaks, one of which is quite severe. Please retest with the candidate update, once it's built, and let me know if the server's memory usage continues to grow without apparent bound -- on my test systems, it's affected (sometimes contrary to my expectations) somewhat by the cache sizes set in the server's cn=config entry.
(In reply to comment #3) > 0.31 and later fix some memory leaks, one of which is quite severe. Please > retest with the candidate update, once it's built, and let me know if the > server's memory usage continues to grow without apparent bound -- on my test > systems, it's affected (sometimes contrary to my expectations) somewhat by the > cache sizes set in the server's cn=config entry. Yeah - there appears to be a memory leak if the cache is too small to hold all of the entries. What happens then is that the entries are churned - repeatedly added and deleted - there must be either a memory leak during deletion, or just the accumulated memory fragmentation over time that causes the memory usage to go up. This may be https://fedorahosted.org/389/ticket/51 - the solution for that is to make sure the nsslapd-cachememsize is large enough to contain all of the data.
slapi-nis-0.34-1.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/slapi-nis-0.34-1.fc15
slapi-nis-0.34-1.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/slapi-nis-0.34-1.fc16
Package slapi-nis-0.34-1.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing slapi-nis-0.34-1.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-0722/slapi-nis-0.34-1.fc16 then log in and leave karma (feedback).
slapi-nis-0.36-1.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.
slapi-nis-0.36-1.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.