在我们的ASP.Net网站上,我们有一些请求超时.AppDynamics显示SQL过程调用在几秒钟内返回,但我们在SNIReadSyncOverAsync中花费了100多秒.
有谁知道这个方法是什么/做什么以及为什么要花那么多时间？我们没有使用在我能够找到的每个问题/帖子中引用的EF.
提前致谢
更新
已经有一段时间了,虽然我们从来没有解决为什么所有的时间都花在SNIReadSyncOverAsync上,但我有一些想法.
我认为在这种情况下,它可能是特定版本的AppDynamics报告SQL调用所用时间的方式,但我没有真正的数据来支持这一点,只是我从我观察到的猜测.我们最终停止看到报告的时间在SNIReadSyncOverAsync中花费,并且它转移到查询本身超时.
由于相同的查询将在同一数据库中的SSMS中立即运行,因此仍然没有做很多事情.
最终答案最终与ARITHABORT相关,导致我们的应用程序和SSMS使用两个不同的执行计划(请参阅https://dba.stackexchange.com/a/9841),解释了为什么我们无法使用SSMS重现超时.
一旦我们解决了这个问题,我们就能够确定需要调整的过程的一些部分,并且我们没有遇到无法解释的超时或SNIReadSyncOverAsync.
我正在对使用EF(System.Data.Entities)从sql DB读取的WCF服务进行一些分析.当我启动多个并行服务器的客户端时,CPU都会达到100%,性能通常是坦克,一切都陷入困境.
在使用并发分析器进行分析时,我发现85%的时间花在同步上,只有大约4%是实际的代码执行.深入研究堆栈跟踪,大多数同步似乎来自System.Data.SqlClient.TdsParserStateObject.ReadSniSyncOverAsync中对WaitForSingleObject的调用.堆栈显示调用转到本机方法包装器,然后在kernel32.dll!_WaitForSingleObject结束.
有谁之前经历过这个吗？对此有什么办法吗？我并没有真正抛出荒谬的负载,只有大约20个并行客户端,并且它都是只读的,所以我很惊讶线程甚至会费心去同步.
我已经和它斗争了一个星期了,我无法解释它.任何帮助,将不胜感激!