mpm_winnt with LDAP httpd child process using 100% CPU workaround

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
</Location>

# 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.

085:a1c
libaprutil_1!apr_reslist_cleanup_order_set+0xc2
libaprutil_1!apr_rmm_calloc+0x84
mod_ldap+0x61d9
mod_ldap+0x6907
mod_ldap+0x39f2
mod_authnz_ldap+0x1ae3
mod_auth_basic+0x17f7
libhttpd!ap_run_check_user_id+0x35
libhttpd!ap_process_request_internal+0x3c4
libhttpd!ap_die+0x4bf
libhttpd!ap_die+0x577
libhttpd!ap_psignature+0x1865
libhttpd!ap_run_process_connection+0x35
libhttpd!ap_regkey_value_remove+0x1603
kernel32!BaseThreadInitThunk+0xd
ntdll!RtlUserThreadStart+0x1d

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.
************************************************************
Received on 2014-05-01 13:21:42 CEST