在部署新版本的混合asp.net Web应用程序Framework 4.5.1，IIS 7.5之后，我们立即注意到CPU使用率达到了100％。
我使用DebugDiag跟踪CPU峰值调试，如本文所述：http://www.iis.net/learn/troubleshoot/performance-issues/troubleshooting-high-cpu-in-an-iis-7x-application-pool
我现在有了我的报告，并且每个被识别为高CPU使用率问题的线程都是这样的，具有不同的线程数：
Thread 1576 - .SNIReadSyncOverAsync(SNI_ConnWrapper*, SNI_Packet**, Int32)
我猜这意味着罪魁祸首是LINQ to SQL调用。该应用程序使用了大量的LINQ to SQL。不幸的是，DebugDiag报告没有提供关于哪个LINQ to SQL调用导致困难的线索。
有没有办法使用DebugDiag报告中的信息来识别导致高CPU使用率的SQL Server调用？
答案 0 :(得分：0)
我们从来没有找到问题的答案。我希望得到一个答案，告诉我们可以添加到性能监视器数据集合中的内容，以查看正在加入CPU的线程传递的实际SQL。
相反，我们运行了SQL Server性能监视器，经过适当过滤以仅覆盖来自Web应用程序的流量，大约一分钟。我们将收集到的所有数据转储到表中，然后检查语句的开始和结束时间，以识别占用过多时间的语句。从这些缓慢的语句集合中，我们确定了SQL调用，它正在加速CPU。
奇怪的是，SQL调用（选择内联表值函数的结果）需要2-3秒才能完成，但大部分时间是在sql server断开连接（sp_reset_connection）时进行的。调用本身在不到一毫秒的时间内返回，当我们使用相同的参数在SSMS中执行相同的函数时，调用在不到一毫秒的时间内执行。但是，这将是一个单独问题的主题。