Using searchrate/mutrace there is a contention on pthread_mutex_init. fixing this contention give a throughput gain (~15%)
1.4.3
Import 100K entries + searchrate
/lib64/libmutrace.so(pthread_mutex_init+0xf4) [0x7fef8b5082d4] /sbin/ns-slapd(connection_table_get_connection+0x1b3) [0x41c5c5] /sbin/ns-slapd() [0x421563] /sbin/ns-slapd() [0x41ea0e] /sbin/ns-slapd(slapd_daemon+0x743) [0x41f87e] /sbin/ns-slapd(main+0xead) [0x428786] /lib64/libc.so.6(__libc_start_main+0xf3) [0x7fef8acdf1a3] /sbin/ns-slapd(_start+0x2e) [0x411a4e]
No contention at this point
Metadata Update from @tbordaz: - Issue assigned to tbordaz
Metadata Update from @mreynolds: - Custom field origin adjusted to None - Custom field reviewstatus adjusted to None - Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1843604
Metadata Update from @mreynolds: - Issue priority set to: major - Issue set to the milestone: 1.4.2 - Issue tagged with: Performance
Oppss... likely a mistake with my runs as I am not able to reproduce the gain/contention. Need a deeper look
Metadata Update from @tbordaz: - Issue untagged with: Performance - Issue priority set to: None (was: major) - Issue set to the milestone: None (was: 1.4.2)
@tbordaz No, this is possible. conntable.c line 254, we init the mutex in the connection slot, if the slot is in the state "free". IE it's never been allocated yet. So at start up there is a burst of connections into the conntable, and the freelist will iterate over every slot, causing every new connection to use a new slot. After a period of time, every slot will have been allocated so in connection_table_get_connection the condition on line 249 will be skipped over, and then this contention on "init" will go away.
An option is to move the pthread_mutex_init into connection_table_new line 168, and similar for the pdumutex. This way all the work is done at start up, in a single thread, and it would mean we spend less time under the conntable ct lock.
Another improvement here is that we could move the ct mutex to be finer grained before we call connection_cleanup, as there is no need to do that under the ct lock.
@tbordaz this PR would address your comments
https://pagure.io/389-ds-base/pull-request/51134
Metadata Update from @mreynolds: - Issue priority set to: normal - Issue set to the milestone: 1.4.3 - Issue tagged with: Performance
Metadata Update from @firstyear: - Issue close_status updated to: fixed - Issue status updated to: Closed (was: Open)
@tbordaz I've closed this as I merged it, but would be cool for you to retest now.
a1c8e12..7e1d80f 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/4184
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.