[Date Prev][Date Next]
Re: (ITS#3471) multiple syncrepl clients blocks other syncrepl clients
- To: openldap-devel@OpenLDAP.org
- Subject: Re: (ITS#3471) multiple syncrepl clients blocks other syncrepl clients
- From: Howard Chu <firstname.lastname@example.org>
- Date: Thu, 20 Jan 2005 14:54:51 -0800
- In-reply-to: <200501192228.j0JMSDYj069599@boole.openldap.org>
- References: <200501192228.j0JMSDYj069599@boole.openldap.org>
- User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a5) Gecko/20041101
email@example.com wrote:Well, this problem turns out to be quite Solaris-specific. First of all,
once the server got busy, it stopped listening to incoming connections.
Attaching with gdb showed that the main listener thread was waiting in
thread_yield (ldap_pvt_thread_yield) (see line slapd/daemon.c:1720)
after having returned from select() with a result of zero (timeout).
Apparently the listener thread was not getting back onto the CPU at all
while the other threads were running, so it never got back around to
select() for new connections again. (The yield at daemon.c: 1969 also
seems to be a problem.)
Since the problem is not occurring on Linux, it appears this is a
Solaris-specific issue. It sounds very similar to the problem in
ITS#3340. Not clear whether it's thread related or something else.
--On Friday, January 07, 2005 8:04 PM +0000 openldap-its@OpenLDAP.org wrote:
Just to follow up, this scenario actually blocks *all* other incoming
connections (i.e., you can only have two active connections, everything
else times out).
Commenting out this yield call seems to have helped that part of the
problem. We then found that even though the connections stopped timing
out, there still wasn't very good response from slapd. Attaching with
gdb at this point showed multiple threads stuck in a mutex_lock invoked
from the syslog() function.
I think we may need these yield() calls on a single-CPU machine, to make
sure that incoming operations aren't starved for CPU time. But the test
machine is a multi-CPU machine, so that kind of consideration doesn't
apply. Also, since this piece of code just loops back to select(), we
probably can avoid the yield's altogether when we know that select
yields. configure already tests for that, so perhaps we can just
surround these calls with #ifndef HAVE_YIELDING_SELECT.
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
Symas: Premier OpenSource Development and Support