On Tue, Feb 4, 2020 at 9:02 AM Krotil, Radek <radek.krotil_at_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
Received on 2020-02-04 16:26:33 CET