On 07/24/2014 12:50 PM, Thomas Walker wrote:
On Thu, Jul 24, 2014 at 10:55:54AM -0600, Rich Megginson wrote:
> 1) I think you are running too many threads. Having too many threads causes
> too much thread contention, which leads to performance problems. Did you set
> nsslapd-threadnumber? If so, try setting it to 2 times the number of cores on
> your system. If you didn't touch nsslapd-threadnumber, then it must be a bug,
> because the default number is 30 (for historical reasons).
Thanks, inherited config from a predecessor. Cranked that back down significantly.
> 2) Thread 1 summary:
> fsync fsync ?? vslapd_log_error slapd_log_error_proc_internal
> slapd_log_error_proc handle_pr_read_ready slapd_daemon main
> When doing stack traces, it is best to do it with no additional error log
> levels. This fsync() in the daemon main loop is very expensive.
> 3) There are a lot of stack traces waiting on locks related to virtual
> attribute lookups, for example:
> Thread 86
> ?? ?? ?? ?? PR_vsmprintf slapi_ch_smprintf vattr_map_namespace_sp_getlist
> slapi_vattr_namespace_values_get_sp send_specific_attrs
> send_ldap_search_entry_ext send_ldap_search_entry iterate send_results_ext
> op_shared_search do_search connection_dispatch_operation ?? start_thread clone
Attaching some new stacktraces with those out of the way.
Did the above make any significant difference with respect to the
389 users mailing list