On Tue, Feb 4, 2020 at 9:02 AM Krotil, Radek <radek.kro...@siemens.com> wrote: > From what I understand, the svnserve on Windows can run only in the > threaded mode. On Linux the default is the fork mode, but using the > fork mode may produce significant overhead and excessive memory > allocation due to the caches at high concurrency. So this particular > case where the problem was reported is coming likely from a threaded > svnserve. > > When it comes to comparison of between Windows and Linux deployment, > our experience shows that svnserve stalling happens sooner on > Windows than on Linux using fork mode. Symptoms include all CPU > being burned in svnserve process and long response times in terms of > 100 seconds on SVN side. Note that our application in parallel uses > http connection to get and put data into SVN on behalf of regular > end users, and also system user access via svn protocol and > svnserve. Both Apache and Svnserve are running on top of the same > repository. > > This subject has been opened some 18 months ago as well, and you can > see the history of the conversation at > http://subversion.1072662.n5.nabble.com/Deadlock-like-behaviour-of-svnserve-in-multi-threaded-mode-T-td196421.html#a197955.
I just finished reading the earlier discussions and issue SVN-4626 (https://issues.apache.org/jira/browse/SVN-4626). Some thoughts... There is a combination of several different pieces of software at play here, and the issue could be isolated to one of them, or could be the result of several seemingly unrelated things. It was suggested it could be a regression in svnserve that appeared sometime after Subversion 1.8.x and before 1.9.3. Has anyone tried to run a bisect (between r1467414 and r1718531), to try to nail down a specific change that introduces the issue? SVNKit was mentioned several times. That is a separate project to Subversion. Has anyone been able to reproduce the lockup issue without SVNKit, either by interfacing to the SVN libraries directly, or via the command line client? Is it possible that a regression appeared in SVNKit? Have you tried, for example, using older versions of SVNKit with the newest available Subversion? Or alternately, the newest version of SVNKit with Subversion 1.8.x? Again, this is to try to isolate the issue to one of these pieces of software, or to rule out their involvement. One thing I didn't see was how/why did the discussion end up with the title "Better choice for Linux semaphore than spinlock?" That might be beside the point. > I can pull in additional experts from our team that were involved in > the analysis with Red Hat in detail. We can use all the help we can get! Please feel free to involve every expert who can help. Nathan
