[Date Prev][Date Next]
Pierangelo Masarati wrote:
I know it's not going to be very indicative, since it's mixing reads and
writes and it's yielding overall execution time and not operations rate;
but it looks indicative.
Yes, as an indicator of the problem I'm sure it's Good Enough.
I found that recompiling daemon.c with #undef HAVE_EPOLL brought
performance back in line with my other results for the BROKEN/select
case, going down from 17 minutes back to ~25 seconds. So there appears
to be some bad interaction between select() and epoll() in the same
process, how nice.
Notice http://article.gmane.org/gmane.linux.kernel/368066 - the
pthread_mutex_unlock() function is broken as well, which is what
necessitated some of these additional yield() calls in the first place.
Other solutions I've investigated: pthread_attr_setscope( xxx,
PTHREAD_SCOPE_PROCESS ) to request that slapd's threads only compete
within their own process. But this returns Unsupported, so that option
Playing with scheduling policies and thread priorities requires root
access, so that can't be done for a slapd running as a non-root user.
All in all the Linux 2.6 kernel is pretty unsatisfactory at the moment,
and there are no clean fixes presenting themselves.
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/