While working on virtual attribute lock contention (ticket 512). I setup a stap script to monitor that contention. The script also reported a high contention on a entry cache lock. This is an unexpected side effect of the script that was suppose to only report virtual attribute lock contention.
How to reproduce - Identify the entry cache lock address, attach gdb to DS
(gdb) break cache_return Breakpoint 1 at 0x7fafee0320e0: file ldap/servers/slapd/back-ldbm/cache.c, line 1106. (gdb) cont Continuing. [Switching to Thread 0x7fafd77fe700 (LWP 5965)] Breakpoint 1, cache_return (cache=0x1385808, ptr=0x7fafd77f72b0) at ldap/servers/slapd/back-ldbm/cache.c:1106 1106 if (NULL == ptr || NULL == *ptr) (gdb) print cache->c_mutex $1 = (PRLock *) 0x13356a0 - use the attached stap script. Use the test case described in ticket512.
The script will report (/tmp/stap_output) a set of high contention lock. One of them is the cache->c_mutex (look for its address for example 0x13356a0)
The data showing the contention (Look into /tmp/stap_output)
lock 0x13356a0 contended 2243 times, 19707 avg us ... Histogram 0x13356a0 value |-------------------------------------------------- count 0 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 421 1000 |@@ 28 2000 |@@@@ 53 3000 |@@@ 40 4000 |@@@@ 55 5000 |@@@ 43 6000 |@@ 36 7000 |@@@@ 54 8000 |@@@ 43 9000 |@@@@ 55 10000 |@@@ 49 11000 |@@ 34 12000 |@@@@ 54 13000 |@@@@ 52 14000 |@@ 36 15000 |@@@@ 52 16000 |@@@ 39 17000 |@@@ 45 18000 |@@ 29 19000 |@@ 36 20000 |@@@ 42 21000 |@@ 32 22000 |@@@ 43 23000 |@@@ 43 24000 |@@ 37 25000 |@ 20 26000 |@@@ 40 27000 |@@@ 49 28000 |@@ 29 29000 |@@ 29 30000 |@ 23 >30000 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 602
attachment vattr_contention.sh
attachment vattr_contention.stp
Metadata Update from @tbordaz: - Issue assigned to tbordaz - Issue set to the milestone: 1.4 backlog
Entry cache will be impacted by database format change. Contention on it is not a priority over database change and contention would likely change after this change.
Closing it as will not fix
Metadata Update from @tbordaz: - Issue close_status updated to: None
Metadata Update from @tbordaz: - Issue close_status updated to: wontfix - Issue status updated to: Closed (was: Open)
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/614
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.
Login to comment on this ticket.