none
Problem about SqlConnectionPool RRS feed

  • Question

  • Hello,

      recently i have developed a windows service-hosted wcf service, but after running for some time the service didn't response at all, the cpu,memory compustion is normal and network is connected, sql server connectivity is ok, so i create a dump file to see what exactly happend in the process,i opened the dump file in windbg and didn't see any exception throwed,  but there are many unstarted threads, almost 1030, then i used !threadpool to get the following results:

    0:000:x86> !tp
    WARNING: clr overlaps MSVCR100_CLR0400
    *** WARNING: symbols timestamp is wrong 0x4ba2211c 0x4dd234a8 for clr.dll
    CPU utilization: 0%
    Worker Thread: Total: 1023 Running: 1023 Idle: 0 MaxLimit: 1023 MinLimit: 8
    Work Request in Queue: 3423
        AsyncTimerCallbackCompletion TimerInfo@0000000000733498
        AsyncTimerCallbackCompletion TimerInfo@00000000007335d8
        AsyncTimerCallbackCompletion TimerInfo@0000000000733498
        AsyncTimerCallbackCompletion TimerInfo@0000000000733498
        AsyncTimerCallbackCompletion TimerInfo@0000000000733498
        AsyncTimerCallbackCompletion TimerInfo@00000000007335d8
        AsyncTimerCallbackCompletion TimerInfo@0000000000733498

        .....

    every thread in thread pool point to location 0000000000733498 or 00000000007335d8.

    finally i got these two methods, they are

    0:000:x86> !ip2md 6ff1b0ec
    The version of SOS does not match the version of CLR you are debugging.  Please
    load the matching version of SOS for the version of CLR you are debugging.
    CLR Version: 10.0.30319.1
    SOS Version: 4.0.30319.237
    MethodDesc:   6fab4de0
    Method Name:  System.Data.ProviderBase.DbConnectionFactory.PruneConnectionPoolGroups(System.Object)
    Class:        6fa9c890
    MethodTable:  6fb628a4
    mdToken:      fe3cc64906001a66
    Module:       6fa81000
    IsJitted:     yes
    CodeAddr:     6ff1b0ec
    Transparency: Safe critical

    and

    0:000:x86> !ip2md 6ff4aff0
    The version of SOS does not match the version of CLR you are debugging.  Please
    load the matching version of SOS for the version of CLR you are debugging.
    CLR Version: 10.0.30319.1
    SOS Version: 4.0.30319.237
    MethodDesc:   6fab5010
    Method Name:  System.Data.ProviderBase.DbConnectionPool.CleanupCallback(System.Object)
    Class:        6fa894e4
    MethodTable:  6fb62ccc
    mdToken:      fe3cc64906002141
    Module:       6fa81000
    IsJitted:     yes
    CodeAddr:     6ff4aff0
    Transparency: Safe critical

    so, could these be the cause of the wcf service hanging, if it is, then what can cause sqlconnectionpool post so many requests to thread pool. i already put every method uses sqlconnection in using {}.

    .net framework: 4.0

    my connection string is:Data Source=xxx;Initial Catalog=xxx;User ID=xxx;Password=xxx

    provider name:System.Data.SqlClient

    Sql server version: sql server 2012 x64 standard edition

    thanks very much.

    Monday, November 30, 2015 1:37 AM

All replies

  • Hi Wzh1986,

    1.

    Check if SqlCommands is dispose when you have finished with them

    Check if SqlConnection is close when you have finished with them

    Check if SqlDataReader is close when you have finished with them

    2.

    ADO.NET 2.0 introduced two new methods to clear the pool: ClearAllPools and ClearPool. ClearAllPools clears the connection pools for a given provider, and ClearPool clears the connection pool that is associated with a specific connection. If there are connections being used at the time of the call, they are marked appropriately. When they are closed, they are discarded instead of being returned to the pool.

    You could try to use SqlConnection.ClearAllPools()  which you could catch some exceptions

    Best Regards,

    cole


    Thursday, December 3, 2015 7:51 AM
    Moderator
  • Hi,

      cole wu, thanks for replying, it would be helpful, i will check these points, add ClearAllPools() to code and  test it in my environment.

    Best Regards.

    Friday, December 4, 2015 2:51 AM