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. 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. 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.
SVN 1.8.8 - svn: E175012: Connection timed out
A week ago I upgraded our server from 1.7.5 to 1.8.8. On an automated build machine we had no issues with timeouts in 1.7.5. However, after upgrading to 1.8.8, client CLI as well, I am running into this time out error about 60% of the time. I have at least one other user running into this as well. Any ideas or suggestions as to how to correct or work around this issue? Thanks Tom
Re: SVN 1.8.8 - svn: E175012: Connection timed out
Tom Kielty writes: > A week ago I upgraded our server from 1.7.5 to 1.8.8. On an automated build > machine we had no issues with timeouts in 1.7.5. However, after upgrading > to 1.8.8, client CLI as well, I am running into this time out error about > 60% of the time. I have at least one other user running into this as well. > > Any ideas or suggestions as to how to correct or work around this issue? If you were using a 1.7 client over HTTP with the default neon library then the default HTTP timeout was 60min. The 1.8 client no longer supports neon and uses serf instead and the default HTTP timeout is now 10min. You can change the client timeout by changing the 'http-timeout' setting in the client configuration. -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
Git Patch fails to apply with Svn Patch
I was running "svn patch" with a patch I created with "git diff" and it failed to apply, however it applies just fine with the default "patch" command on my Rhel 6.5 system. This is due to the "extended header" information that git puts before the actual diff in some cases. I validated this by removing the lines beginning with "old mode" and "new mode" in the patch below (file "PATCH2") and then "svn patch" applied the patch successfully. I'd like to request that "svn patch" be able to ignore this extended header information and be able to apply the patch successfully without getting the "skipping missing target" error. I guess there's an argument that some of this extended header info should be processed by "svn patch" but for, for my purposes, it would be enough that it ignored it and applied the rest of the patch. Here's an example (in this case the extended header is describing a chmod change to the target file, indicated by the "old mode" and "new mode" lines): *$ cat PATCH2* *diff --git a/Makefile b/Makefile* *old mode 100644* *new mode 100755* *index caef0a5..310e8e9* *--- a/Makefile* *+++ b/Makefile* *@@ -5,6 +5,7 @@ export BUILD_SYS_ROOT* * export BUILD_TARGET_ROOT* * export BUILD_DIR* * export CMAKE_PASSTHROUGH_ARGS* *+export ADD_FAKE_VARIABLE* * export DESTDIR* * export DISTPKG_LOC* * export WITH_MOVER* *$ svn patch PATCH2* *Skipped missing target: 'b/Makefile'* *Summary of conflicts:* * Skipped paths: 1* *$ patch -p1 < PATCH2* *patching file Makefile* *$ svn diff* *Index: Makefile* *===* *--- Makefile (revision 42326)* *+++ Makefile (working copy)* *@@ -5,6 +5,7 @@* * export BUILD_TARGET_ROOT* * export BUILD_DIR* * export CMAKE_PASSTHROUGH_ARGS* *+export ADD_FAKE_VARIABLE* * export DESTDIR* * export DISTPKG_LOC* * export WITH_MOVER* Thanks for your consideration of this request, Eric Berge Senior File System Developer, StorNext File System Quantum Corporation eric.be...@quantum.com P.S. Just for your reference, if you're curious about what the full set of "extended header" info git generates, the following is from the git-diff man page from the version (1.8.2.1) running on my system: old mode new mode deleted file mode new file mode copy from copy to rename from rename to similarity index dissimilarity index index ..
