On 14.04.2016 18:14, Radek Krotil wrote:
> Hi all.
>
> Our application generates lot of concurrent read requests to subversion using
> svn: protocol. When we tested the multithreaded mode of svnserve after upgrade
> to 1.9.3, we noticed strange 'deadlock-like' behavior: at some point all the
> requests are blocked in svnserve and wait there for a few minutes (3 to 15
> minutes, no CPU activity), after which they continue to work. This is making our
> application significantly slower.
In 1.9.x we switched to thread pools and limited their number
to give some control over the memory usage. The limiting code
might interact with your requests, though.
The number of concurrent connections should not be a problem,
the threads only become active whenever there is an actual
request from the client side (like a c/o, log etc.). What
kind of requests are being served? How long to the connections
live (one new connection per request?).
You might try setting "--min-threads" and "--max-threads" to
large values such as 64 for the lower limit (default is 1) and
1024 for the upper limit (default is 64 on 32 bits and 256 with
64 bit versions of svnserve). Monitor the memory usage, though!
Let us know if that helped.
-- Stefan^2.
Received on 2016-04-24 21:43:19 CEST