[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: ITS#3950

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 is out.

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/