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 can pull in additional experts from our team that were involved in the analysis with Red Hat in detail.
Best regards,
Radek Krotil
Siemens Digital Industries Software
Polarion ALM Product Management
polarion.plm.automation.siemens.com<https://polarion.plm.automation.siemens.com/>
From: Nathan Hartman <hartman.nathan_at_gmail.com>
Sent: Tuesday, February 4, 2020 12:55 PM
To: Krotil, Radek (DI SW LCS PMT ALM) <radek.krotil_at_siemens.com>; Subversion Developers <dev_at_subversion.apache.org>
Subject: Re: Better choice for Linux semaphore than spinlock?
On Tue, Feb 4, 2020 at 6:45 AM Krotil, Radek <radek.krotil_at_siemens.com<mailto:radek.krotil_at_siemens.com>> wrote:
Hi All.
I believe this issue originates at one of our customer and is related how Polarion ALM is using Subversion at scale. This is a reoccurring issue being encountered by several enterprise customers and I’d be more than happy to help the community to pin it down and get it fixed. Has there been any update since October on this problem?
I think there haven't been any changes in this area but we will definitely appreciate your help.
The underlying cause might be in the APR (Apache Portable Runtime) libraries, which Subversion uses for its platform independence, or could be in the choice of APR APIs used somewhere in svnserve.
By the way, are you doing a threaded or non-threaded build?
Nathan
-----------------
Siemens Industry Software, s.r.o.
Praha 4, Doudlebská 1699/5, PSČ 140 00
IČ 256 51 897
Zapsaná v obchodnÃm rejstÅ™Ãku vedeném MÄ›stským soudem v Praze, oddÃl C, vložka 58222
Důležité upozornÄ›nÃ: Tato zpráva má jen informativnà charakter. Obsah této zprávy odesÃlatele nezavazuje a odesÃlatel nemá v úmyslu touto zprávou uzavÅ™Ãt smlouvu, pÅ™ijmout nabÃdku, potvrdit uzavÅ™enà smlouvy ani nezakládá pÅ™edsmluvnà odpovÄ›dnost jejÃho odesÃlatele, ledaže je odesÃlatelem ve zprávÄ› uvedeno výslovnÄ› jinak. Obsah této zprávy (vÄetnÄ› pÅ™Ãloh) je důvÄ›rný. Pokud nejste zamýšleným adresátem této zprávy, zpÅ™ÃstupnÄ›nÃ, kopÃrovánÃ, distribuce nebo užità obsahu zprávy je pÅ™ÃsnÄ› zakázáno a v takovém pÅ™ÃpadÄ›, prosÃm, okamžitÄ› informujte odesÃlatele a poté zprávu (vÄ. pÅ™Ãloh) odstraňte z VaÅ¡eho systému.
Important Note: This message is only of informative nature. The content of this message shall not be binding for sender and sender does neither intend to conclude contract, accept offer or confirm the conclusion of the contract by this message nor this message represents pre-contractual liability of the sender, unless the sender states in the message excplicitly otherwise. The content of this message (including appendices) shall be confidential. Should you are not intended receiver of this message, any access, copying, distribution or use of the content of this message is strictly prohibited and in such case, please immediately notify the sender and subsequently delete the entire message (including apppendices) from your system.
Received on 2020-02-04 15:02:28 CET