[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Better choice for Linux semaphore than spinlock?

From: Ruediger Pluem <rpluem_at_apache.org>
Date: Mon, 7 Oct 2019 21:51:40 +0200

On 10/07/2019 08:40 PM, Branko Čibej wrote:
> On Mon, 7 Oct 2019, 19:47 Doug Robinson, <doug.robinson_at_wandisco.com <mailto:doug.robinson_at_wandisco.com>> wrote:
>
> 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).

Regards

Rüdiger
Received on 2019-10-07 21:51:46 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.