Post reply

Task was forced to yield

  • March 21, 2012 at 9:29 pm

    #270524

    Saw the following errors in my log tonight. Just so happens that it occurred during a time when the client experienced some major slowness.

    2012-03-21 19:14:52.49 spid59 Task (Worker 0x000000035969E1C0) was forced to yield 3 times: SomeDatabase.dbo.cs_aspx_OrderEntry;1

    2012-03-21 19:14:52.67 spid139 Task (Worker 0x000000097FF8A1C0) was forced to yield 5 times: SomeDatabase.dbo.cs_aspx_OrderEntry;1

    2012-03-21 19:14:52.76 spid128 Task (Worker 0x000000062C3D21C0) was forced to yield 4 times: SomeDatabase.dbo.cs_aspx_OrderEntry;1

    2012-03-21 19:14:55.04 Logon Error: 17892, Severity: 20, State: 1.

    2012-03-21 19:14:55.04 Logon Logon failed for login 'usrSomeDatabase' due to trigger execution. [CLIENT: 192.168.100.49]

    2012-03-21 19:14:55.84 spid151 Error: 18056, Severity: 20, State: 1.

    2012-03-21 19:14:55.84 spid151 The client was unable to reuse a session with SPID 151, which had been reset for connection pooling. This error may have been caused by an earlier operation failing. Check the error logs for failed operations immediately before this error message.

    2012-03-21 19:14:55.84 spid87 Task (Worker 0x0000000A925C41C0) was forced to yield 4 times: SomeDatabase.dbo.cs_aspx_OrderEntry;1

    2012-03-21 19:14:56.53 spid122 Task (Worker 0x00000010F90841C0) was forced to yield 2 times: SomeDatabase.dbo.cs_aspx_OrderSummary;1

    Now the code above does contain CLR code that calls a 3rd party inventory system. I mention this because what little data I can find on the issue references CLR's.

    Anyone got an idea what is going on and/or can help me figure out what is going. Could use some help. I have seen it in older error logs as well.

    Fraggle

  • March 22, 2012 at 2:07 am

    #1462541

    You've got a CLR proc that's heavy on CPU usage and does not have any sleeps or other voluntary yields in it. So after it has spend some time on the CPU, the SQL scheduler forces it to yield, puts it at the back of the runnable queue, essentially penalising it for being heavy on CPU usage.

    Gail Shaw
    Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
    SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

    We walk in the dark places no others will enter
    We stand on the bridge and no one may pass

  • March 22, 2012 at 7:30 am

    #1462699

    Gila,

    Any idea how I can find this?

    Thanks,

    Fraggle

  • March 22, 2012 at 7:33 am

    #1462703

    Find what?

    Gail Shaw
    Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
    SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

    We walk in the dark places no others will enter
    We stand on the bridge and no one may pass

  • March 22, 2012 at 7:59 am

    #1462725

    Gail,

    Is there a way to find out which CLR is causing the issues? Both of the procs listed contain multiple CLR's.

    Additionally, just in general, how do I monitor CLR performance, and not just for CPU. Memory, disk utilization, etc

    Thanks,

    Fraggle

  • March 22, 2012 at 8:28 am

    #1462748

    Do some monitoring and correlate query execution with the error log events.

    Gail Shaw
    Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
    SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

    We walk in the dark places no others will enter
    We stand on the bridge and no one may pass

Viewing 6 posts - 1 through 5 (of 5 total)

You must be logged in to reply to this topic. Login to reply