subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Krotil, Radek" <>
Subject Re: Better choice for Linux semaphore than spinlock?
Date Tue, 04 Feb 2020 11:01:40 GMT
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?
On the customer end the problem is easy to detect, where almost all CPU is consumed by svnserve
process, while more than 95% of the CPU is spent in system time, leaving almost no throughput
for the actual operation.
Best regards,
Radek Krotil

Siemens Digital Industries Software
Polarion ALM Product Management<>

On 2019/10/12 23:29:44, eponymous alias <> wrote:
>  Perhaps these links might be of help in some way:>
> On Monday, October 7, 2019, 1:56:14 PM PDT, Doug Robinson <>
> Rüdiger:>
> On Mon, Oct 7, 2019 at 3:51 PM Ruediger Pluem <> wrote:>
>  On 10/07/2019 08:40 PM, Branko Čibej wrote:>
>  > On Mon, 7 Oct 2019, 19:47 Doug Robinson, < <>>
>  >>
>  > Folks:>
>  >>
>  > I spoke with this user late last week. They stated that they can only get approximately
400 parallel SVN operations>

>  > before the "system time" consumes all available CPU for an 8-core machine. Adding
more cores won't help because of>

>  > the nature of spin locks (it makes things worse). Turns out that even with ~100
parallel SVN operations the "system>

>  > time" starts becoming significant/measurable (~10%). Both HTTP (mod_dav_svn) and
"svnserve" protocols participate>

>  > in the lock contention.>
>  >>
>  > Your help would be greatly appreciated.>
>  >>
>  > Whew. So. Reducing this issue to "use a more efficient lock" is not going to work,
and you provided far too little>

>  > information to even attempt a diagnosis. For starters, I recommend gathering as
much info as possible (anonymised of>

>  > course) about the server configuration, everything from httpd an svnserve to the
repository config and underlying>

>  > filesystem, if possible. Getting stack traces of the "stuck" threads would be necessary,
too. Without knowing exactly>

>  > what is happening, these kinds of problems are extremely hard to understand, let
alone fix.>
>  Plus depending on which part of the code requires this lock a different locking mechanism
that might suit better for>

>  this use case can possibly be chosen via configuration changes (e.g. httpd allows this
for most of its locking).>
> That would be awesome! I'll definitely try to get those stack tracebacks.>
> Cheers.>
> Doug>
>   >

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.

View raw message