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

Re: Deadlock-like behaviour of svnserve in multi-threaded mode (-T)

From: Ivan Zhakov <ivan_at_visualsvn.com>
Date: Fri, 15 Apr 2016 10:45:33 +0300

On 14 April 2016 at 19:14, Radek Krotil <radek.krotil_at_polarion.com> 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.
>
> Operating system: Windows 10, CentOS 6.6, CentOS 7.2
>
> The release and/or revision of Subversion: 1.9.3
>
> The compiler and configuration options you built Subversion with: WANDisco
> binaries for CentOS, Apache Haus binaries for Windows
>
> The workaround on Linux is to run svnserve without -T switch, i.e. not using
> multithreaded mode. For Windows, there is no workaround as svnserve only
> supports the multi-threaded mode.
>
> Here is a sample of thread dump of svnserve.exe during the 'deadlock'
> obtained on Windows 10 using Process Explorer:
>
> ntoskrnl.exe!KeSynchronizeExecution+0x3de6
> ntoskrnl.exe!KeWaitForMutexObject+0xc7a
> ntoskrnl.exe!KeWaitForMutexObject+0x709
> ntoskrnl.exe!KeWaitForMutexObject+0x375
> ntoskrnl.exe!IoThreadToProcess+0xff0
> ntoskrnl.exe!KeRemoveQueueEx+0x16ba
> ntoskrnl.exe!KeWaitForMutexObject+0xe8e
> ntoskrnl.exe!KeWaitForMutexObject+0x709
> ntoskrnl.exe!KeWaitForMutexObject+0x375
> ntoskrnl.exe!NtWaitForSingleObject+0xf2
> ntoskrnl.exe!setjmpex+0x3963
> ntdll.dll!NtWaitForSingleObject+0x14
> MSWSOCK.dll!Tcpip6_WSHSetSocketInformation+0x155
> MSWSOCK.dll+0x1bf1
> WS2_32.dll!WSAAccept+0xce
>
> WS2_32.dll!accept+0x12
> libapr-1.dll!apr_socket_accept+0x46
> svnserve.exe+0xc11c
> svnserve.exe+0xbae5
> svnserve.exe+0xaf6c
> svnserve.exe+0x13ab
> KERNEL32.DLL!BaseThreadInitThunk+0x22
> ntdll.dll!RtlUserThreadStart+0x34
>
> The similar stack can be seen with other threads too.
>
1. Do you have debug symbols for Subversion binaries you're using?
2. Other threads should have different stack trace, because AFAIK only
one thread calls accept().
3. Could you please create full memory dump of locked process and send
it to me including debug symbols?

-- 
Ivan Zhakov
Received on 2016-04-15 09:46:09 CEST

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