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