Description of problem: According to the design document of the new autotuning feature, we can set nsslapd-cache-autosize-split to 0 and it will give 40% of memory to dbcache and 60 to entrycache. Currently, when we set nsslapd-cache-autosize-split to 0 it makes nsslapd-dbcachesize = 0.
Version-Release number of selected component (if applicable): 389-ds-base-1.3.6.1-13.el7.x86_64
How reproducible: Allways
Steps to Reproduce: 1. Install the instance 2. Stop the instance 3. In the dse.ldif, set nsslapd-cache-autosize-split: 0 (cn=config,cn=ldbm database,cn=plugins,cn=config). 4. Start the instance 5. Check nsslapd-dbcachesize value: [root@test upstream]# ldapsearch -h localhost -p 389 -D "cn=Directory manager" -w Secret123 -b "cn=config,cn=ldbm database,cn=plugins,cn=config" -s base nsslapd-dbcachesize dn: cn=config,cn=ldbm database,cn=plugins,cn=config nsslapd-dbcachesize: 0 6. Check errors log: [root@test upstream]# tail /var/log/dirsrv/slapd-test/errors [19/May/2017:09:59:08.985987463 -0400] - INFO - main - slapd stopped. [19/May/2017:10:00:32.418844117 -0400] - INFO - main - 389-Directory/1.3.6.1 B2017.125.237 starting up [19/May/2017:10:00:32.427530683 -0400] - INFO - ldbm_instance_config_cachememsize_set - force a minimal value 512000 [19/May/2017:10:00:32.433748015 -0400] - NOTICE - ldbm_back_start - found 1883520k physical memory [19/May/2017:10:00:32.435366864 -0400] - NOTICE - ldbm_back_start - found 1558272k avaliable [19/May/2017:10:00:32.436475963 -0400] - NOTICE - ldbm_back_start - cache autosizing: db cache: 0k [19/May/2017:10:00:32.437401841 -0400] - NOTICE - ldbm_back_start - cache autosizing: userRoot entry cache (1 total): 196608k [19/May/2017:10:00:32.439956036 -0400] - NOTICE - ldbm_back_start - total cache size: 218103808 B; [19/May/2017:10:00:32.441461907 -0400] - INFO - dblayer_start - Resizing db cache size: 61719183 -> 0 [19/May/2017:10:00:32.515365798 -0400] - INFO - slapd_daemon - slapd started. Listening on All Interfaces port 389 for LDAP requests
Actual results: nsslapd-dbcachesize was set to 0.
Expected results: nsslapd-dbcachesize should be set to the value of 40% from allocated memory.
Metadata Update from @spichugi: - Custom field component adjusted to Database - Performance - Custom field origin adjusted to QE - Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1452739 - Custom field type adjusted to defect - Custom field version adjusted to 1.3.6
Metadata Update from @firstyear: - Issue assigned to firstyear
@spichugi Did you make a lib389 test for this case? Wondering if I should or if you already have one?
<img alt="0001-Ticket-49267-autosize-split-of-0-results-in-dbcache-.patch" src="/389-ds-base/issue/raw/files/b2750629fb851eac81a04baa1b6790ec4d1f8dd09cda6f8f141f0adf6d1b5f85-0001-Ticket-49267-autosize-split-of-0-results-in-dbcache-.patch" />
@spichugi This should fix it for you :)
Sorry about the triple post, pagures issues are getting insane ...
Metadata Update from @mreynolds: - Custom field reviewstatus adjusted to ack (was: review)
commit 22d4865 To ssh://git@pagure.io/389-ds-base.git d3aa098..b81c8ba master -> master
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/2326
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: fixed)
Login to comment on this ticket.