subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weisser, Mark S (CTO Architecture + Engineering)" <>
Subject mpm_winnt with LDAP httpd child process using 100% CPU workaround
Date Thu, 01 May 2014 11:20:51 GMT
Another thread with subject "Re: Subversion 1.8 httpd.exe taking 100% CPU" describes a 100%
CPU condition that sporadically occurs in the single httpd child process when using mpm_winnt
with LDAP authentication. We have been experiencing this issue 2 or 3 times a week since upgrading
to Subversion 1.8. The issue continued for us through the following version:

[Wed Apr 23 04:15:17.065606 2014] [mpm_winnt:notice] [pid 1728:tid 436] AH00455: Apache/2.4.9
(Win64) SVN/1.8.8 OpenSSL/1.0.1g configured -- resuming normal operations
[Wed Apr 23 04:15:17.065606 2014] [mpm_winnt:notice] [pid 1728:tid 436] AH00456: Server built:
Apr  8 2014 03:06:16

I think that we found a possible workaround. Since we made the following changes to our httpd.conf
the looping condition causing the 100% CPU usage has not reoccurred from the date and time
of the log message above (8 days):

# Allow LDAP cache (if any) to be examined at runtime.
<Location /server/cache-info>
    SetHandler ldap-status

# LDAP Cache settings:
# Only one httpd child so shared cache is not needed.
LDAPSharedCacheSize 0
LDAPCacheEntries 2048
LDAPCacheTTL 900
LDAPOpCacheEntries 32
LDAPOpCacheTTL 600

My conjecture is that the "LDAPSharedCacheSize 0" is the significant change. Since mpm_winnt
has only 1 child process there is no reason to use a shared cache. The stack trace of the
looping threads is similar to the one captured below which seems to point in this direction
as well.


I am reluctant to fiddle any more with these settings to affirm this with 100% confidence
as our server is working nicely for now. Perhaps someone else experiencing the 100% CPU issue
can give the "LDAPSharedCacheSize 0" a try.

mark w
This communication, including attachments, is for the exclusive use of addressee and may contain
proprietary, confidential and/or privileged information.  If you are not the intended recipient,
any use, copying, disclosure, dissemination or distribution is strictly prohibited.  If you
are not the intended recipient, please notify the sender immediately by return e-mail, delete
this communication and destroy all copies.

View raw message