[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).


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.