2

After deploying a new version of a hybrid asp.net web application, Framework 4.5.1, IIS 7.5, we immediately noticed that CPU usage was spiking to 100%.

I followed CPU spike debugging using DebugDiag as described in this article: http://www.iis.net/learn/troubleshoot/performance-issues/troubleshooting-high-cpu-in-an-iis-7x-application-pool

I now have my report, and every one of the threads identified as High CPU usage problems look like this, with varying thread numbers: 

Thread 1576 - .SNIReadSyncOverAsync(SNI_ConnWrapper*, SNI_Packet**, Int32)

I'm guessing this means the culprit is a LINQ to SQL call. The application uses a lot of LINQ to SQL. Unfortunately the DebugDiag report gives no clue as to which LINQ to SQL call is causing the difficulty.

Is there any way to use the information in the DebugDiag report to identify the SQL Server calls that causes the High CPU usage?

Tom Regan
  • 3,580
  • 4
  • 42
  • 71
  • This might help: http://stackoverflow.com/questions/14609129/cpu-usage-of-w3wp-rises-to-100-on-a-asp-net-mvc4-web-application. The solution suggested is to rebuild the VM. – HashPsi Dec 03 '15 at 17:03

1 Answers1

0

We never did find an answer to the question. I was hoping for an answer that would tell us what we could add to the performance monitor data collection to see the actual SQL that was being passed by the threads that were spiking CPU.

Instead we ran SQL Server performance monitor, duly filtered to cover only traffic from the web application, for about a minute. We dumped all the data collected into a table, then examined statement start and end times to identify statements that were taking an inordinate amount of time. From this collection of sluggish statements we identified the SQL call that was spiking CPU.

Oddly enough, the SQL call (selecting the results of an Inline Table-Valued Function) takes 2-3 seconds to complete, but most of that time is taken with sql server breaking the connection (sp_reset_connection). The call itself returns in less than a millisecond, and when we execute the same function in SSMS using identical parameters the call executes in less than a millisecond. However, this will be the topic of a separate question.

Tom Regan
  • 3,580
  • 4
  • 42
  • 71